642155 - news.morningstar.com -- does not display dynamic element (mouseover/hover infoboxes) properly

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[CS]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

This Morningstar page (like others) has a dynamic element that fails to display correctly in FF4.  (Works correctly in IE, FF3.6)

Correct behavior: Each security symbol (e.g., TWTIX) shows a float-over panel showing a chart and some links, providing information about the security.

In FF4 what shows instead is a blank rectangle on the page with a "loading" graphic.

Reproducible: Always

Steps to Reproduce:
1.  Go to the URL pasted above (available to the public).
2.
3.
Actual Results:  
See above

Expected Results:  
See above

You have enough info to reproduce

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirmed with Mozilla/5.0 (Windows NT 5.1; rv:2.0b13pre) Gecko/20110316 Firefox/4.0b13pre ID:20110316030411.

Spoofing the User Agent to e.g. Firefox 3.6.15 does not help.

Last good nightly: 2010-08-27 First bad nightly: 2010-08-28

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124

Alice, can you help bisect?

Comment 2

[Alice0775 White]

(In reply to comment #1)

> Alice, can you help bisect?

What is dynamic element ?
Please provide incorrect/correct screenshot

Comment 3

[Alice0775 White]

(In reply to comment #2)
> (In reply to comment #1)
> 
> > Alice, can you help bisect?
> 
> What is dynamic element ?
> Please provide incorrect/correct screenshot

Never mind.

Disabled html5 helps.

Comment 4

[(mostly gone) XtC4UaLL [:xtc4uall]]

Attachment: Screenshot showing the Issue (Trunk vs GC)

Alice: expected is that on hovering over the Abbreviations you get the Graph displayed correctly.

Comment 5

[Alice0775 White]

And  
UA spoofing helps with enabled HTML5.
user_pref("general.useragent.override", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Minefield/4.0b5pre");

So, I think this is the site Issue.

TE?

Comment 6

[Alice0775 White]

Regression range(cached m-c hourly):
Works:
http://hg.mozilla.org/mozilla-central/rev/a6c18a123fbb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Minefield/4.0b5pre ID:20100827075702
Fails:
http://hg.mozilla.org/mozilla-central/rev/cf4d7946e2e0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre ID:20100827101721
Pushlog
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a6c18a123fbb&tochange=cf4d7946e2e0
Triggered by:
2914a4cdd7e2	Dan Witte — Bug 588874 - Replace Minefield with Firefox in UA string. r=khuey, sr=jst, a=beta5+

However, According to comment #4 , this bug should be TE.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Yeah, sounds like this site is sniffing for "Firefox" and doing something bogus if it finds it, while sending other browsers through a different codepath that works just fine in Firefox.

Comment 8

[Chris Lawson (gone)]

CS: Please report this to Morningstar, as I'm sure they'll listen to customers more than they'll listen to us. Feel free to point them to this bug and we're more than happy to help them fix it.

Comment 9

[CS]

Chris,

Thanks, I barely beat you to it ... I just reported this to Morningstar, with specific details.

I want to express appreciation to the team for the prompt and thorough attention this received.

Comment 10

[Andrew Lee]

After analyzing the bug, I have determined it is caused by the forceful termination of paragraphs that contain any other block level elements. For example, currently the generated popup is built in such a way that there are several nested divs. For simplicity, it's basically structured as:
<p>
    <div>content</div>
    <div>content</div>
</p>

Firefox 4 terminates the paragraph tag and forces the div elements out:
<p></p>
<div>content</div>
<div>content</div>
<p></p>

This causes CSS selectors to no longer apply to the nested divs and also breaks the JS interactions. I understand that nesting divs inside of p tags is bad practice, as p's are not grouping elements and is non-semantic markup, but I feel that forcing and re-positioning elements to standards is not the correct approach either. This is handled without issue in other browsers except FF4. Is there any workaround to stop this forceful behavior without having to completely refactor and re-architect the entire method and construction?

Thanks,
Andrew
Front End Developer
Morningstar

Comment 11

[Boris Zbarsky [:bzbarsky]]

Andrew, thanks for looking into this!

I just tried your simple testcase in a few browsers.  You can do the same by loading http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%3E%0A%20%20%20%20%3Cdiv%3Econtent%3C%2Fdiv%3E%0A%20%20%20%20%3Cdiv%3Econtent%3C%2Fdiv%3E%0A%3C%2Fp%3E and looking at the "DOM view" pane.

I see the <p> closed by <div> in the following browsers:  Firefox 3.6, Firefox 4, Opera 11, Safari 5, Chrome 11 dev, MSIE 9.

In fact, websites depend on <div> inside <p> closing the <p>.  Changing that behavior would break things all over the place.

So what does your markup that behaves differently in Firefox 3.6 and Firefox 4 actually look like?  It's hard to say how you can fix things without knowing that.

Comment 12

[Andrew Lee]

I think I over simplified my test case. The problem is further complicated with nested span elements that also wrap around the divs. I think the major difference is that other browsers force close the p element but maintain the inner relationship between the spans and divs, while FF4 completely forces the divs out while still maintaining the spans inside the paragraph. Thanks for the demo, this further helps me understand the problem a little better. I will take some time to further investigate on the exact cause and perhaps come up with a fix.

Comment 13

[Andrew Lee]

Here is an example of the pop-up that is generated:

<span width='315px' class='smartChart' z_index='300' mCharts='TWTIX' ticker='TWTIX' index='1' style="display:none;">
    (
    <A href='http://quote.morningstar.com/Switch.html?ticker=TWTIX'>TWTIX</A>
    <span class='smartChartTag'>
        <div class='msSmall' style='background:#666666; height:15; width:305' id='TOPTWTIX1'></div>
        <div class='gBorderDiv'>
            <TABLE WIDTH='100%' style='background:#eeeeee;' height='155' BORDER='0' CELLSPACING='0' CELLPADDING='0'>
                <TR height=20px >
                    <TD colspan=2 width =100% align=left valign=top bgcolor=#eeeeee><div class ='gDiv1' id='TWTIX1'></div></TD>
                    <TD bgcolor='#eeeeee'><img border='0' width=12 src='http://im.morningstar.com/im/dot_clear.gif'></TD>
                </TR>
                <TR>
                    <TD><img border='0' width=5 src='http://im.morningstar.com/im/dot_clear.gif'></TD>
                    <TD width =268 align=center valign=middle bgcolor=#fafae6><img class='quoteTipChart' border='0' src='http://tools.morningstar.com/webgraphs/images/LoadingScreenAnimation.gif'chartAddress='http://tools.morningstar.com/webgraphs/miniCharts.aspx?Security=TWTIX&TimeFrame=YTD'></TD>
                    <TD bgcolor='#eeeeee'><img border='0' width=12 src='http://im.morningstar.com/im/dot_clear.gif'></TD>
                </TR>
            </TABLE>
            <div align='left' style='background:#eeeeee; height:52; WIDTH=303'>
                <TABLE WIDTH='272' height='40' BORDER='0' CELLSPACING='0' CELLPADDING='0'>
                    <TR>
                        <TD class='msSmall' align= 'left' valign='top' >Sponsored by:</TD>
                        <TD align='right' WIDTH='89' valign='middle'><span id='ADTWTIX1' index='TWTIX' ntotal='1' style='background:#eeeeee'></span></TD>
                    </TR>
                </TABLE>
            </div>
        </div>
	</span>
    )
</span>

Wrapping this within p tag, you can see that FF3 keeps the structure in tact. FF4 however forces the divs out, while maintaining the spans inside the p. I think the only solution is to refactor the functionality so that it's more compliant and the content is injected outside of the paragraphs.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Short of changes to the HTML5 parsing algorithm, I suspect so, yes...  Henri, any idea what's going on here, exactly?

Comment 15

[Henri Sivonen (:hsivonen)]

(In reply to comment #14)
> Short of changes to the HTML5 parsing algorithm, I suspect so, yes...  Henri,
> any idea what's going on here, exactly?

<div> now closes <p> even if there's a <span> in between.

IE8 and earlier created a non-tree DOM for <p><span><div>, so standardizing what IE8 and earlier did was not an option. HTML5 standardized what pre-HTML5 WebKit (including Safari 5) did. This is different from what pre-HTML5 Gecko did. In old Gecko, the span masked the <p> from <div> processing. In WebKit and HTML5 it doesn't.

Now Firefox 4, IE9 (standards mode), Safari, Chrome and Opera (Ragnarök build) all do the same thing. Interop FTW, so no algorithm change expected.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Hmm.  Given that and comment 7, it sounds like just changing the "Firefox" codepath to behave like the "Minefield" or "Safari" one should make things work...

Comment 17

[Karl Dubost💡 :karlcow]

Let's assume that the bug has been resolved.