Closed Bug 1213073 Opened 9 years ago Closed 8 years ago

Elements on the left and on the right to news feed on Facebook jitter while scrolling after getting new activities

Categories

(Core :: Panning and Zooming, defect, P1)

Product:
Core
Component:
Panning and Zooming
Platform:
Unspecified
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: 2ljpswpih, Unassigned)

References

Details

(Keywords: qawanted, Whiteboard: [apz-evangelism] [needsdiagnosis])

Attachments

(1 file)

1213073-fbcolumns.htm
(deleted), text/html
Details 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151007030205

Steps to reproduce:

Log in Facebook. Go to the beginning of news feed (in setting: "Most recent"), wait for loading of new activities, go up.


Actual results:

Elements on the left (news feed, messages, groups, etc) and on the right to the news feed (information about events, birthdays, etc) go down while scrolling up and go back after end of scrolling.


Expected results:

Elements should not move and stay at one place.
OS: Unspecified → Windows 10
Component: Untriaged → Layout
Product: Firefox → Core
Is this a regression, or has this always been the case?
Keywords: qawanted
I don't understand you much. Do you ask me whether this happened in earlier version? I don't know. But it happens now every time when you are at the beginning of the news feed, get new activities and scroll up.
> Do you ask me whether this happened in earlier version?

Yes.

Unfortunately, your steps to reproduce require a Facebook account, so I can't try this myself; that's why I'm asking you....
Do you need a video of this bug?
No, I believe you it happens.  I need someone with a Facebook account to check whether this is a new problem or something that's been happening for a while.  It doesn't have to be you; that's why I added qawanted.
I don't entirely understand your steps to reproduce, but on Nightly when I scroll up and down on Facebook, the columns move in sync as you would expect.
@ Andrew, I will sent you an e-mail with a video of this bug.
Oh, I missed the part about "wait for loading of new activities". I'll wait for some new content to come in and see what happens.
@ Andrew, I have sent you an example of this bug.
Ok, I got the video, thanks. (You might also want to send it to Boris because he knows much more about these issues than me.)

What it looks like in the video is that there's some new content that comes in, then the user starts scrolling up. The columns at the right and left initially start out touching the top of the screen, but when the scrolling starts, their positioning lags behind the scrolling a bit, so they drift down the screen a bit, then it kind of catches up and pops back towards the top of the screen.

This might just be a result of the way that they implement the columns or something. Do you see this same behavior in Chrome?
That behaviour is not present in Chrome, I think, but I'm not sure of that and I will check it.
I checked this and in Chrome columns don't move, stay at one place. Everything there is ok.
I can also reproduce this.
OS: Windows 10 → All
Version: 44 Branch → Trunk
What happens if you toggle the pref layers.async-pan-zoom.enabled? (Restart of firefox required for changes to take effect to that pref)
How can I do it?
Enter "about:config" into the url bar, then search for layers.async-pan-zoom.enabled.
This fixed that problem.
But the quality of scrolling significantly decreased.
@ Timothy, after today update I noticed changes in display of these two columns. It's slighly better, but not totally. I'll send you another video of it. I got new content, noticed that columns automatically went up above the screen without my scrolling, then I started recording and scrolling and there you will see that these columns stopped behave as you implemented and started as before.
Second time I got new content information, but columns behave as before. So only once after update and logging into Facebook columns behaved a little bit better, but with every new content coming in bug is as reported. I don't know how it will be after logging out and restarting Nightly - whether again first time a little bit better than before or at once bad behaviour of columns.
I was able to reproduce this. It looks like we are not updating fixed position elements in the APZ, only after the content thread updates? Not sure why, Markus, Botond, does that sound like an existing APZ bug you are aware of?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mstange)
Flags: needinfo?(botond)
If I understand you properly, your way to fix it is automatically move columns while getting new content to the beginning of the news feed, even above the screen. In my opinion, Chrome implements it much better. When new content comes in, in Chrome columns stay without movement while getting new content and scrolling up. Of course during usual browsing, scrolling up and down makes columns change their position, but when you are at the top of the news feed and get new content, they don't move, they are at proper position. It is much better than your implementation, because if user leaves Facebook for some time and during this period of time 20 new activities comes in , user will have to scroll up, scroll up and scroll up to get to the beginning of the columns and click, let's say "Messages" or "Events".
I hope you understand what I mean. Sorry for not the best English ;).
(In reply to Timothy Nikkel (:tn) from comment #21)
> I was able to reproduce this. It looks like we are not updating fixed
> position elements in the APZ, only after the content thread updates? Not
> sure why, Markus, Botond, does that sound like an existing APZ bug you are
> aware of?

There are a few outstanding issues related to fixed and sticky position elements, such as bug 1214151, but it's hard to say whether they affect this situation without knowing more about the page structure.

Do you think it might be possible to obtain a testcase that reproduces the problem on demand, by saving the page (with File -> Save Page As) after the update has come in but before the scrolling has occurred?
Flags: needinfo?(botond)
(In reply to to_du from comment #22)
> If I understand you properly, your way to fix it is automatically move
> columns while getting new content to the beginning of the news feed, even
> above the screen. In my opinion, Chrome implements it much better. When new
> content comes in, in Chrome columns stay without movement while getting new
> content and scrolling up.

The page should behave the same as in Chrome after we figure out and fix this issue.
http://telewizjarepublika.pl/szumlewicz-korwin-chce-dogadac-sie-z-pis-tylko-zjednoczona-lewica-jest-antysystemowa,24842.html
I think that this is related with this bug. Scroll down and there is video above the comments. Behaviour similar to behaviour of columns on Facebook.
(In reply to to_du from comment #26)
> http://telewizjarepublika.pl/szumlewicz-korwin-chce-dogadac-sie-z-pis-tylko-
> zjednoczona-lewica-jest-antysystemowa,24842.html
> I think that this is related with this bug. Scroll down and there is video
> above the comments. Behaviour similar to behaviour of columns on Facebook.

I understand the effect is similar, but I believe the underlying problem is different: I think in this case it's related to the video being in a plugin (Flash). I would have expected bug 1137944 to resolve this; since it appears not to have, I'll file a separate bug for it.
(In reply to Botond Ballo [:botond] from comment #27)
> I understand the effect is similar, but I believe the underlying problem is
> different: I think in this case it's related to the video being in a plugin
> (Flash). I would have expected bug 1137944 to resolve this; since it appears
> not to have, I'll file a separate bug for it.

Filed bug 1214878.
(In reply to Timothy Nikkel (:tn) from comment #21)
> I was able to reproduce this. It looks like we are not updating fixed
> position elements in the APZ, only after the content thread updates? Not
> sure why, Markus, Botond, does that sound like an existing APZ bug you are
> aware of?

I'm not aware of any APZ position:fixed bug other than bug 1214151. But I've seen cases on Facebook (not on the activity page, but on somebody's profile page) where Facebook toggles position between fixed and absolute frequently from a scroll handler. Is that what's happening here?
Flags: needinfo?(mstange)
I tried reproducing this but on my Facebook news feed new activities don't seem to come in at all. I left it for hours and didn't get anything new, although after reloading there was clearly new stuff there. This happened for both "Top Stories" and "Most Recent".

That being said, it does look like the sidebar switches between position:fixed and not depending on where you are on the page; near the top it is not fixed and then if you scroll down it becomes fixed. Furthermore the "top" CSS property value is dependent on how tall your browser window is (possibly among other things). If you shorten the window the top becomes more negative so that the bottom of the sidebar content remains in view. I'm not sure if that matters here.
Are you still seeing this issue on a recent nightly build (anything since November 17)? In the last month we've made a bunch of changes to the layout code dealing with fixed-position elements so this might have gotten fixed.
Flags: needinfo?(to_du)
Summary: Elements on the left and on the right to news feed on Facebook are displayed wrong while getting new activities → Elements on the left and on the right to news feed on Facebook jitter while scrolling after getting new activities
For the time being I can't get new activities. I must refresh page to find out whether there are new activities.
That's what I was seeing as well. Brad, you filed bug 1193934 which was the same issue - are you still able to reproduce that? If not I'm inclined to close this bug as WFM.
Flags: needinfo?(to_du) → needinfo?(blassey.bugs)
I still see this same behavior.
No, I don't see this anymore
Flags: needinfo?(blassey.bugs)
Priority: -- → P1
I can confirm that this bug still persists. It must have been Facebook issue, because in every browser new content didn't come in. Today new content appears, in Nightly also and these two columns still jitter.
Thanks, I was able to repro it as well just now. They're changing the margin-top value of the sidebars as you scroll up, but not as you scroll down. I don't think we have any CSS way of doing this - neither position:fixed nor position:sticky is a good alternative.
The changes dvander is working on in bug 1192919 should help here. If scroll events are not uniform (bug 1209970) then fixing that will also help.
Depends on: 1209970, 1192919
The dependencies have landed, so this is probably about as good as we can make it for now.
Blocks: apz-desktop
No longer blocks: all-aboard-apz
Whiteboard: [apz-evangelism]
I just saw this bug without e10s (so without apz), which is weird because that has never happened before. (I've seen the bug with e10s before.)
kats, it seems you analyzed in Comment #38, could you pinpoint which JS/CSS where this is happening. It will help when we need to contact Facebook for fixing the issue if it still exists. (can't check myself no Facebook account here). Thanks.
Flags: needinfo?(bugmail.mozilla)
Whiteboard: [apz-evangelism] → [apz-evangelism] [needsdiagnosis]
Hallvord, can you pick up diagnosis on this one?
Flags: needinfo?(bugmail.mozilla) → needinfo?(hsteen)
I can confirm this bug still persists.
But it happens only with left column.
I've been trying to test this today and I *think* it doesn't happen. Observations:

1) On the newsfeed page (the "main" page after logging in), the left column now scrolls with the main content for me - there's no fixed positioning tricks. 

2. The rightmost "messenger" column stays on screen - .fbChatSidebar has position:fixed. 

3) The column which is second from right ("suggested groups", adverts) has a "sticky"-like effect (but it seems to vary from load to load depending on its content - if there are ads, they stick to the screen while you scroll to remain in the viewport while "suggested pages" and other FB features don't.). It's technically achieved by setting position:fixed and top:-185px (or some other value to hide the FB features) on a descendant of the rightCol element.


So far the main page. I notice no problems on scrolling. Since nothing in the left column is fixed on scrolling now I'm not sure if this bug is still an issue?

Also, I don't see any new content being appended to the top of the newsfeed above your scroll position.

However, if I go to my own profile (or another profile page or "Facebook Page", i.e. for an organisation/company), the left column changes and aquires more content. Now it shows among other things friends and images I uploaded - and it does get fixed in the viewport on scrolling. Technically, what happens is that an OL element (!) gets position:fixed and top:-550px when you've scrolled down a while. On scrolling up, the position:fixed is changed to position:absolute;top:10px at a certain scroll position, and then again switched to normal in-flow state without position when the absolute value is removed.

If other people write on my wall, I get a notification icon - no content appears automatically here either. However, if other people *comment on* posts on my timeline ("wall"), those comments *do* appear immediately. I didn't see any particular jitter when scrolling up or down before and after such comments appeared. I guess if you're at an exact scroll position and incoming comments make the page longer, the position:fixed->absolute->static logic described above might cause some odd effect, but it should be rare and not really severe.

If it still happens for others, a video and/or some very carefully described steps to reproduce it would be great!
Flags: needinfo?(hsteen)
@Hallvord, go to the main page, set to the "Most recent" and wait some time for new content. When it happens, scroll up. That's all.
Check your email, in a few minutes I will sent you a video of it.
I will sent you this in 2 hours.
Email has been sent.
(In reply to to_du from comment #47)
> @Hallvord, go to the main page, set to the "Most recent" and wait some time
> for new content. When it happens, scroll up. That's all.

Yes, this is what happens for me, too. I tend to leave the page scrolled partway down, so maybe that is related. I get a little button sort of thing in the middle column that says something about how there are more updates. It is certainly much better than it was before, but the left column doesn't quite stay stuck to the top of the window.
Facebook confuses me. I've had it open all day - this morning it did behave much like described, adding new content above scroll position and being somewhat jittery when scrolling up. However, all of a sudden it decided to stop doing that - for the rest of the day it never repositioned the left menu at all..

Anyway, I confirm that the positioning of the left column is achieved by setting margin-top from scroll events, this can not really be smooth with the async implementation. I'll attach a demo, sort of, not based on FB code but my assumptions about what it does.
Attached file 1213073-fbcolumns.htm (deleted) — 
Demo. Observe left menu while scrolling down and up.
I don't know whether new bug related with this appeared in Nightly or it is a Facebook bug, but now I get information about new content, but no new content appears. I'll check it in Chrome.
Ok, I have checked one more time and there is no new behaviour.
It seems like this doesn't happen on Facebook anymore because the news feed doesn't fetch new things. Hallvord has a test case in comment 52 which simulates the problem, but the proper fix is on Facebook's end - so if it isn't reproducible on the real site this bug is WFM.

I'm marking it dependent on bug 1246290 anyway, so if it comes back we can reopen this bug and use bug 1246290 as the backup plan to fix it.
Status: NEW → RESOLVED
Closed: 8 years ago
Component: Layout → Panning and Zooming
Depends on: 1246290
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: