57054 - Image (MAP) renders incorrectly at msnbc.com (<MAP> should be display:inline; in quirks mode)

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Chris Petersen]

Build: 2000101608
Platform:All
Expected Result: Image to be inline in TD element.
What I got: Image renders on top of second image in the TD element.

Steps to reproduce:

1) Go to www.msnbc.com
2) In top portion of the table, one image is rendered on top of another.
3) See attachment.
4) This problem is related to a Map element being rendered as block. It is most 
noticeable when the MAP element is contained in a TD with other inline elements.

Comment 1

[Chris Petersen]

This bug is related to 57028
http://bugzilla.mozilla.org/show_bug.cgi?id=57028

Comment 2

[Chris Petersen]

Attachment: A sample of a Map inside a TD with inline element

Comment 3

[karnaze (gone)]

Reassigning to Buster (from Clayton).

Comment 4

[Chris Petersen]

This is a popular web site and problem is highly noticeable. Nominating RTM.

Comment 5

[lchiang]

Is this a top100?  If so, pls add the keyword.

Comment 6

[rickg]

Marking top 100.

Comment 7

[Chris Petersen]

Attachment: Map issue on mactopia.com site

Comment 8

[Chris Petersen]

Simular problem on Microsoft's Mac site (www.mactopia.com).  A Map and image are
contained in the same TD element. Map and image should be inline. But map is
rendered as block and image is rendered below.

Comment 9

[buster]

It turns out that if we make <map> display: inline; in quirks.css, then we are
compatible with Nav4/IE5 and we fix a whole lot of pages that now have extra
line breaks.

Comment 10

[buster]

cc-ing some folks from bug 11431

Comment 11

[buster]

Attachment: proposed quirks-mode fix

Comment 12

[buster]

PDT: this fix is extremely safe with respect to stability.  It also gets us
much, much closer to backwards compatible layout on several top100 pages.
Finally, it has no effect on standards or forward compatibility, because it only
effects quirks mode layout.  I think this is a very straightforward fix to take.

Comment 13

[buster]

Attachment: oops, this is the REAL patch

Comment 14

[Chris Waterson]

r=waterson (or sr, whichever you need)

Comment 15

[rickg]

r=rickg. I've also tested this against the top 100 and it looks fine.

Comment 16

[buster]

whiteboard -> rtm+ and reviewer annotations
also, through private email ian agrees that this is a legit quirks-mode solution

Comment 17

[Jim Roskind]

We'll hold this bug at RTM plus until we have a fallback candidate RTM bulid in 
our pocket, and then we'll reconsider (and probably take).

Comment 18

[selmer (gone)]

This bug is in candidate limbo.  We will reconsider this fix once we have a 
candidate in hand, but we can't take this fix before then.

Comment 19

[selmer (gone)]

We are moving toward the candidate.  Please check this fix into the trunk so we 
can get get some cook time.

Comment 20

[buster]

checked into trunk

Comment 21

[Phil Peterson]

PDT marking [rtm++]. This bug is now out of limbo and approved for checkin to
the branch. Please check in ASAP.

Comment 22

[buster]

fix checked into branch

Comment 23

[Chris Petersen]

Fixed in the Oct 31 branch build.

Comment 24

[Peter Trudelle]

Looks good using 10-31-14 MN6 candidate build on Win98

Comment 25

[Kathleen :Brade]

also looks good on Macintosh ns6 build from 2000103114

Comment 26

[buster]

*** Bug 57028 has been marked as a duplicate of this bug. ***

Comment 27

[Asa Dotzler [:asa]]

Verified Fixed on Mozilla trunk builds
linux 122710 RedHat 6.2
win32 122705 NT 4
mac 122708 Mac OS9
Setting bug to Verified and removing vtrunk keyword