distler Reporter
	Description • 18 years ago

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061119 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061119 SeaMonkey/1.5a

In a nutshell, <math display="block"> is centered in its containing box, rather than making room for a float.

This appears to be a regression, as older builds took account of floats. I will attach two screenshots illustrating the old (correct) behaviour (in the release version of Camino) and the new (incorrect) behaviour (in a current nightly build of Seamonkey).

Reproducible: Always

Actual Results:  
Equation is centered in its containing box (and hence partially obscured by the float).

Expected Results:  
The float should be taken into account in determining how to center the equation.

	Phil Ringnalda (:philor)
	Comment 3 • 18 years ago

I've no idea what's "right," but the behavior changed between 2006-09-21 20:00 and 2006-09-24 23:00, which covers The Night of MathML Checkins: bug 353897, bug 325222, bug 354090, bug 353876 and bug 353894.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 4 • 18 years ago

This is a consequence of giving that block a space manager, so regression from bug 239919.  Perhaps it should also have -moz-float-edge set appropriately or something?  rbs, how should the rendering here work out (e.g. if there were a border on the <math>, where should it appear on this site)?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 5 • 18 years ago

At least part of the issue, of course, is that the SPACE_MGR bit affects interaction with both floats inside the box and floats outside it... :(  It'd be nice if it were possible to create ones own space manager and preinitialize it with all the rects from the ancestor's space manager or something for cases like this.

	-fullmetaljacket-
	Comment 6 • 18 years ago

i am also seeing this on 

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a1) Gecko/20061203 Minefield/3.0a1 ID:2006120322 [cairo]

	Martijn Wargers (dead)
	Comment 7 • 18 years ago

(In reply to comment #4)
> This is a consequence of giving that block a space manager, so regression from
> bug 239919. 

You probably mean a regression from bug 353894? Or bug 353894?

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 8 • 18 years ago

Er, yes.  Dunno where the other came from....

	distler Reporter
	Comment 9 • 18 years ago

>rbs, how should the rendering here work out (e.g. if there were a
border on the <math>, where should it appear on this site?

Dunno where it "should" appear; putting a dashed purple border around <math> and and a blue border around each of the first children of <math>, you can see where it *does* appear in the modified testcase.

	Daniel Veditz [:dveditz]
	Comment 10 • 18 years ago

Will have to catch this one in the next release, missing 1.8.1.1

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 11 • 18 years ago

rbs, what do you think?

	rbs
	Comment 12 • 18 years ago

I am in the midst of a workshop -- will get home later and get back to you tomorrow with my feedback.

	rbs
	Comment 13 • 18 years ago

Comment on attachment 247461 [details] [diff] [review]
So perhaps like this?

r+sr=rbs. This is indeed the effect we want. We do always want to center the block <math> from within the space left after placing the float.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 14 • 18 years ago

Fixed on trunk.

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 15 • 18 years ago

Comment on attachment 247461 [details] [diff] [review]
So perhaps like this?

Fixes regression from earlier crash fix...

	Daniel Veditz [:dveditz]
	Comment 16 • 18 years ago

Comment on attachment 247461 [details] [diff] [review]
So perhaps like this?

approved for 1.8/1.8.0 branches, a=dveditz for drivers

	Boris Zbarsky [:bzbarsky] Assignee
	Comment 17 • 18 years ago

Fixed for 1.8.1.2 and 1.8.0.10..

Someone who knows MathML a lot better than I would need to add a regression test for this...

	alice nodelman [:alice] [:anode]
	Comment 18 • 18 years ago

Confirmed problem in Firefox 2.0.0.1 with provided testcases.

Verified correct centering in 2.0.0.2pre and 1.5.0.10pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/2007013007 BonEcho/2.0.0.2pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.10pre) Gecko/20070130 Firefox/1.5.0.10pre

The second test case does still display oddly for 1.5.0.10pre - the provided boarders don't appear to be entirely respected.  We may need to look into that and open a secondary bug.