Open Bug 1305744 Opened 3 years ago Updated 8 months ago

Twitter profile picture glitches when the page is scrolled in maximized window

Categories

(Web Compatibility :: Desktop, defect, P5)

defect

Tracking

(platform-rel -, firefox49 wontfix, firefox50 wontfix, firefox51 wontfix, firefox52 wontfix, firefox-esr52 fix-optional, firefox53 wontfix, firefox54 fix-optional)

Tracking Status
platform-rel --- -
firefox49 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox-esr52 --- fix-optional
firefox53 --- wontfix
firefox54 --- fix-optional

People

(Reporter: JuliaC, Unassigned)

References

()

Details

(Whiteboard: [platform-rel-Twitter])

[Affected versions]:
- Latest Nightly 52.0a1 (2016-09-26)
- Latest Aurora 51.0a2 (2016-09-27)
- 50.0b2 build1 (20160926162149) 
- 49.0.1 build3 (20160922113459)

[Affected platforms]:
- Windows 10 Pro x64
- Ubuntu 16.04 LTS x64 
- Mac OS Sierra 10.12.1 Beta

[Steps to reproduce]:
1. Launch Firefox and maximize the window
2. Go to a random twitter account (e.g.  https://twitter.com/firefox)
3. Scroll up and down through the page 
 - observe the changes that happen to the twitter profile picture 
4. Redimension the browser window to its default size and scroll again through the page
 - observe the changes that happen to the twitter profile picture 
5. Maximize again the browser window 
 - observe the changes that happen to the twitter profile picture 

[Expected result]:
- [steps 3 and 5] The profile picture changes are the same every time user scrolls the page in maximized window (the profile picture is completely hidden during the scrolling) 

[Actual result]:
- [step 5] After the redimension, the profile picture is partially stuck during the scrolling  (see the screencast https://drive.google.com/file/d/0B-B8HwBlbdDXV1lLRE5Vb1BOMUU/view?usp=sharing)

[Regression range]:
- Last good revision: 2114ef80f6ae (2014-11-06)
- First bad revision: b62ccf3228ba (2014-11-07)
- Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2114ef80f6ae&tochange=b62ccf3228ba


[Additional notes]:
- The issue also occurs if first opening the chosen twitter profile page using the default Firefox window size
Priority: -- → P5
I cannot reproduce this issue on OS X 10.10 with Aurora.

It seems they use negative margin-top to control the position. Not sure why that doesn't work properly here.
platform-rel: --- → ?
Whiteboard: [platform-rel-Twitter]
I reproduced this on Windows. It seems that the margin-top is wrong after the steps. And the margin-top is assigned from script, so we need to know how the script calculate that number.

My guess is that, there might be some timing issue that when some event is dispatched (likely resize), some dimension has not been updated properly, and consequently the script picks the old value at that moment and use it forever.
(In reply to Iulia Cristescu, QA [:IuliaC] from comment #0)
> [Regression range]:
> - Last good revision: 2114ef80f6ae (2014-11-06)
> - First bad revision: b62ccf3228ba (2014-11-07)
> - Pushlog:
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2114ef80f6ae&tochange=b62ccf3228ba

The most likely change in there is https://hg.mozilla.org/mozilla-central/rev/a75897e664dd .  Is this e10s only?  (That is, does enabling/disabling e10s make the bug appear/disappear, both around the regression date or at the present?)
Flags: needinfo?(iulia.cristescu)
See Also: → 1295195
After looking into the code of Twitter, I'm pretty sure it is actually a bug of Twitter, and I can actually reproduce this with Chrome as well.

A detailed reliable reproduce steps:
1. open a Twitter profile
2. resize the window horizontally to make it just don't have the horizontal scrollbar (so narrow enough)
3. resize the window vertically as much as possible
4. scroll down a bit to make the avatar be in the navbar
5. maximize the window

With this steps, I can reproduce this issue on both Firefox and Chrome.


The reason is that, in resize event, Twitter runs the following function for calculating the position:
> this.setResponsiveVariableValues = function () {
>   this.profileHeaderHeight = this.$profileHeader.height(),
>   this.canopyLockPosition = this.profileHeaderHeight - this.attr.finalHeaderHeight
> },
and afterward, it reuses canopyLockPosition to compute the margin-top of the header picture.

This doesn't seem very harmful, until you see what $profileHeader's height actually is.

So $profileHeader's height is responsive to the width of the window, which changes in several steps. In addition to that, this element has a "transition: height .3s". It means that, when resize happens, the height of $profileHeader is still changing. When the difference of the height is big enough, the result of canopyLockPosition would based on a significantly different value than it should have.

So it is a bug of Twitter, not us, and this bug should either be closed as invalid, or be moved to Tech Evangelism.
(In reply to David Baron :dbaron: ⌚️UTC-7 from comment #3)
> (In reply to Iulia Cristescu, QA [:IuliaC] from comment #0)
> > [Regression range]:
> > - Last good revision: 2114ef80f6ae (2014-11-06)
> > - First bad revision: b62ccf3228ba (2014-11-07)
> > - Pushlog:
> > https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2114ef80f6ae&tochange=b62ccf3228ba
> 
> The most likely change in there is
> https://hg.mozilla.org/mozilla-central/rev/a75897e664dd .  Is this e10s
> only?  (That is, does enabling/disabling e10s make the bug appear/disappear,
> both around the regression date or at the present?)

Hello! Sorry for the delay! The issue is reproducible with both e10s on and off.
Flags: needinfo?(iulia.cristescu)
Component: Layout → Desktop
Product: Core → Tech Evangelism
we are a week away from RC, no fix in sight, this is now a wontfix for 50.
platform-rel: ? → -
Since this also happens in Chrome this isn't a priority for our team, but if someone would like to get in touch with Twitter to let them know about their bugs, that's cool.
Dees, is this something you could help facilitate?
Flags: needinfo?(dchinniah)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #8)
> Dees, is this something you could help facilitate?

Sure thing. I will add yourself to the DL - and you can use that channel.
Flags: needinfo?(dchinniah)
I received confirmation from the folks at Twitter that they can reproduce and will continue investigating on their end.
I *think* this might now be fixed but I could be performing the STR incorrectly.
Too late for a fix for 53, fix-optional for 54, minor carryover regression.
Hello!

This issue is still reproducible on:
Fx 53.0b9
Fx 54.0a2 (20170406004017)
Fx 55.0a1 (20170405030213)

Try to use the arrow keys (up and down) to scroll in order to reproduce the issue.

Cheers!
Removing regression keyword since this is a site bug.
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.