1314640 - Title layout bug causes pixel mosh pit in "Advancing WebRTC" blog after clicking any (More...) link

Status: NEW

(Core :: Layout, defect, P3)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: AdvancingWebRTCLayoutBug.png

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).

Comment 1

[Timothy Nikkel (:tnikkel)]

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).

Comment 2

[Timothy Nikkel (:tnikkel)]

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?

Comment 3

[Timothy Nikkel (:tnikkel)]

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.

Comment 4

[Maire Reavy [:mreavy]]

(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.

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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).

Comment 6

[Timothy Nikkel (:tnikkel)]

(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.

Comment 7

[Timothy Nikkel (:tnikkel)]

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.

Comment 8

[Andreas Pehrson [:pehrsons]]

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

Comment 9

[Maire Reavy [:mreavy]]

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.

Comment 10

[Maire Reavy [:mreavy]]

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!

Comment 11

[Ryan Watson [:w0ts0n]]

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.

Comment 12

[Maire Reavy [:mreavy]]

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.

Comment 13

[Timothy Nikkel (:tnikkel)]

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

Comment 14

[Ryan Watson [:w0ts0n]]

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

Comment 15

[Andreas Pehrson [:pehrsons]]

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.

Comment 16

[John Vazquez]

Attachment: same problem

Thanks from sagoocena1984.