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

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P5)

Description

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

[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

Comment 1

[Xidorn Quan [:xidorn] UTC+10]

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.

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

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.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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?)

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

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.

Comment 5

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

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

Comment 6

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

we are a week away from RC, no fix in sight, this is now a wontfix for 50.

Comment 7

[Mike Taylor [:miketaylr]]

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.

Comment 8

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

Dees, is this something you could help facilitate?

Comment 9

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

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

Comment 10

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

I received confirmation from the folks at Twitter that they can reproduce and will continue investigating on their end.

Comment 12

[Andrew Overholt [:overholt]]

I *think* this might now be fixed but I could be performing the STR incorrectly.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix for 53, fix-optional for 54, minor carryover regression.

Comment 14

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

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!

Comment 15

[Mike Taylor [:miketaylr]]

Removing regression keyword since this is a site bug.

Comment 16

[Oana Arbuzov [:oanaarbuzov]]

Attachment: NoGlitch.gif

The layout has changed and the issue no longer occurs.

Tested with:
Browser / Version: Firefox Nightly 84.0a1 (2020-11-11)
Operating System: Windows 10 Pro