867569 - Buttons not working on Talk Talk Help page

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[WaltS48 [:walts48]]

A user reported this in mozilla.support.firefox about Firefox 20.0.1 on Windows 8.
Other users confirmed, while others said they work for them.
Started Firefox 20.0, with a new profile, no extensions, JavaScript enabled.
Go to http://help2.talktalk.co.uk/contact-us
Navigate to the "Still need to get in touch" section.
Place cursor over an arrow.
Cursor doesn't change to a hand, and buttons can not be activated.
Last worked in Firefox 16.0 in my tests on Linux.
Not working in Firefox 17.0, 20.0, 21.0b5, or 23.0a1 for me.
Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0

Comment 1

[Alice0775 White]

Attachment: archive zip (Open index.html )

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/a501733bc7b5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120723064843
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/4c9ee7535383
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120723085942
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a501733bc7b5&tochange=4c9ee7535383

Suspected : Bug 772690

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (no red is is visible in Firefox 16)

Here's a reduced testcase. This is purely visual - no need for hovering / clicking. (This is a display-list-ordering thing, so it can be seen visually as well as through hit-testing.)

In Firefox 16, no red is visible in this testcase.

In Firefox 17 and in current nightly, red is visible (mostly covering the lime div).

So we've basically got a relatively positioned inline, with an abspos child and a block-styled ::after pseudo-element -- and there's a fight for who-goes-in-front between the abspos child and the pseudo-element.  In Firefox 16, the abspos child goes in front, but Bug 772690 apparently made the ::after pseudo-element go in front.)

Comment 3

[Daniel Holbert [:dholbert]]

[keeping needinfo=me to get more details on specifically how/why Bug 772690 changed the rendering, and if there are any obvious fixes]

Comment 4

[Daniel Holbert [:dholbert]]

OK -- so when loading testcase 1  (in a build from fe623d60bea1, just before this regressed), we get a call to IsZOrderLEQ with:
  aItem1 = a display item for the lime abspos child
  aItem2 = a display item for the IB block that wraps the ::after generated content

They both have the same z-index (0), of course, since we haven't set that anywhere.)

So in an old build, we drop into a IsContentLEQ() call on their content nodes. aItem2's content node is the <span>, which is the parent of aItem1's content node. So by content-node, aItem2 is "less than" aItem1. So we return false from IsContentLEQ and as a result from IsZOrderLEQ.

In a newer build, we skip the IsContentLEQ call and just compare the z-indices for <=.  Since they're equal, we return true.

IIRC we thought the IsContentLEQ comparison shouldn't be necessary, because we should be building the display list in content order already (or something along those lines). This bug's situation appears to be an exception to that rule.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (no ::after)

Here's a further-reduced testcase, with a normal div swapped in for the ::after generated content.  Still reproduces the bug. So there's no ::after-dependence here.

Comment 6

[Daniel Holbert [:dholbert]]

(FWIW, chrome dev channel renders testcase 1 as lime (matching old-firefox) but testcase 2 as red (matching new-firefox))

Comment 7

[Alice0775 White]

(Opera 12.15, testcase 1 and 2 both as lime)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 2a (whitespace cleaned up, typo fixed)

Here's a cleaned up (but functionally-equivalent) version of testcase 2, with whitespace removed between tags, for cleaner frame-tree dumps, and with a s/</div>/</span>/ typo-fix.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: slightly altered testcase

This testcase is closely related, but it renders the same in Firefox and Chrome.

What happens here is that the "wrapper-after" element is a block inside the "wrapper" inline. So the "wrapper" inline splits into two frames: an inline frame containing "inner", and a block frame containing "wrapper-after". Both of these frames are position:relative. The position:relative block frame is after "inner" so gets drawn over it.

The spec isn't very clear about this but I suspect it leans towards our old behavior where "wrapper-after" is rendered below "inner". However, Chrome at least doesn't agree. That Chrome renders this testcase differently from the testcase of comment #2 is surely a Chrome bug.

Web developers should avoid putting block elements (or pseudoelements) in inline parents.

Comment 10

[WaltS48 [:walts48]]

User reported in m.s.firefox that they noticed that the buttons started working for them yesterday afternoon, but did not work prior to that.

I just tested in Firefox 17.0.1, 20.0, 21.0b6, and 23.0a1, and the buttons now work in all versions.

Comment 11

[Daniel Holbert [:dholbert]]

(Verified that http://help2.talktalk.co.uk/contact-us seems to have been fixed, so that it doesn't trigger this bug anymore. (using nightly)  I'll bet the user(s) who reported this to us may have reported it to the site as well.)