Unsure if this is a script bug or platform bug. Please re-assign as needed. STR: Open URL. Expected result: - White-on-blue "Advancing WebRTC" in non-scrolling title area, with scrollable text below. Actual result: - White-on-transparent title overlapping black text in scrolling area below, for pixel trash effect. See attached image. Workaround: Any scrolling causes things to pop to expected result. Seen at least on OSX, Windows 10 and linux in release 49, by two people (one report of not seeing it).

Regression window https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dd29535bac5f&tochange=d37d4edce6dd Guessing bug 681192. Maybe the patches from bug 681192 mean we avoid a scroll, and that scroll would have "fixed" the problem (scrolling makes the visual problem go away).

I think a script on the page is getting confused...the element with id=sticker gets the blue/green background color after you scroll, but before you scroll it has a trasparent background. So I think we are rendering the DOM correctly. So the question is why does the script get confused? Because of a bug in Firefox? Or because of a bug in the script?

Looks like the bgcolor comes from the "shrink" class which is set in the scroll event handler of a div which contains almost all the content of the page. Seems like we should probably be calling the scroll event handling in this case.

(In reply to Timothy Nikkel (:tnikkel) from comment #3) > Looks like the bgcolor comes from the "shrink" class which is set in the > scroll event handler of a div which contains almost all the content of the > page. Seems like we should probably be calling the scroll event handling in > this case. Do you believe this is a bug in Firefox or a bug in the page? Do you have a suggested work around and/or fix for the page? Thanks.

FWIW this problem does not appear in Chrome, Safari and Edge when I tried it just now (though I appreciate it is hard to read too much into that).

(In reply to Maire Reavy [:mreavy] from comment #4) > (In reply to Timothy Nikkel (:tnikkel) from comment #3) > > Looks like the bgcolor comes from the "shrink" class which is set in the > > scroll event handler of a div which contains almost all the content of the > > page. Seems like we should probably be calling the scroll event handling in > > this case. > > Do you believe this is a bug in Firefox or a bug in the page? Seems like it's a bug in Firefox, but I haven't checked the spec for when exactly the onscroll handler is supposed to be invoked. > Do you have a suggested work around and/or fix for the page? Thanks. You could call your onscroll handler from a setTimeout(...,0) from the load event of the page.

It seems like the other styles that take affect on the header when the user has scrolled down (smaller font size) seem to be taking effect. So I'm not sure what on the page is making that happen. Applying the background color to the header the same way would probably fix it then.

Maire, who can we get to update the blog's code per the comments above?

Still happens. Updated URL to point to it in the published blog. Most visible if you load the URL (the bug will show and then be covered by the banner), then hit Reload in the URLbar, and the bug will show up and stay visible.

Ryan - Bonfire Red made a fix to style.css (see email from November 28th). Can you verify if this was deployed and the cache was cleared? Thanks!

Hey, can you have them send me the very latest css file? I think it's better to overwrite with latest vs trying to find an old version (just in case other changes were made) and I'll upload and clear cache. Cheers.

The one they sent us on Nov 28th is the latest. No one has made changes since then. If you can deploy that one, we should be good. Thanks.

Can we make sure that a testcase for this remains available somewhere? So that we can fix this bug when we get to it.

I pushed the CSS file a few hours ago and informed :mreavy over email

The site behaves OK for me now. You still see the transparent header background as the page is loading but it gets filled in eventually. In Chrome it seems immediate.