1238503 - [e10s] Elements on page don't immediately respond to page scrolling with mouse wheel

Status: RESOLVED INVALID

(Core :: Performance, defect, P5)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160110030214

> screencast 1:   https://dl.dropboxusercontent.com/s/h0ets9etezed0bp/screencast%201%20-%20Elements%20on%20page%20don%27t%20immediately%20respond%20to%20page%20scrolling.webm?dl=0

STR_1:
0. Set mouse option "When I rotate mouse wheel" to "scroll by 1 page"
1. Open http://www.rp-online.de/
2. Wait until it's fully loaded (blue spinner in tab should disappear)
3. Scroll the page towards the bottom once (= rotate mouse wheel down once)
4. Scroll the page towards the top once (= rotate mouse wheel up once)

Result:       
 After Step 3 header on the page stays at the top side of content area [OK]
 After Step 4 header jumps to its initial position (Step 2) only after scrolling is finished [not OK]

Expectations:
 Header should stay on its initial position (Step 2) _during_ scrolling in Step 4


Caused by bug 1228028. This is blocker. Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0dbac1acaca7ae2a767604fdbcf5105853518c88&tochange=f7ee42669b87f05416eb785ab9db27b5c66de1a3

Comment 1

[arni2033]

STR_2:
0. Set mouse option "When I rotate mouse wheel" to "scroll by 1 page"
1. Open .htm page from "archive 1" in bug 1238504 comment 1 (article saved from www.rp-online.de)
2. Wait until it's fully loaded (blue spinner in tab should disappear)
3. Scroll the page towards the bottom once (= rotate mouse wheel down once)

Result (see "screencast 1" in comment 0):
 The "sticky" ad at the right side jumps at its new position only after scrolling is finished

Expectations:
 The "sticky" ad should follow the visible part of the page, just like before bug 1228028

Comment 2

[Kartikaya Gupta (email:[e-mail])]

The page is simulating position:sticky by using scroll listeners and changing the element from position:absolute to position:fixed. With asynchronous scrolling this is going to be laggy. They should update the site to use the position:sticky CSS property instead. When scrolling down on this page the web console does report a warning about using scroll-linked positioning effects with a link to more info.

Comment 3

[Karl Dubost💡 :karlcow]

This seems to affect Opera on Blink too. So not a Web compatibility issue but more a good practice I guess.
I'm switching to needsdiagnosis aka 
* there are steps to reproduce (good) 
* and an explanation of the source (good) 
* but still lacking which part of the code is creating the issue (not good).


The ads seems to be contained in 
<div id="ftdiv1591664" style="width: 200px; height: 600px; position: absolute; z-index: 77000; left: 1012px; top: 0px;">
    <iframe src="http://cdn.flashtalking.com/53858/1271766/sky.html" 
            name="… see below… " 
            style="position: absolute; top: 0px; left: 0px;" 
            id="ftframe1591664" 
            allowfullscreen="" mozallowfullscreen="" webkitallowfullscreen="" 
            allowtransparency="true" 
            margin="0" 
            scrolling="no" 
            width="200" frameborder="0" height="600">
     </iframe>
</div>

Wow. First time I see this.  They use the name attribute to store a HTML "entitized" JSON file, which is:

{"orientation":90,"state":"default","isViewable":true,"maxWidth":960,"maxHeight":1043,"clicks":{"clickTag":"https://adclick.g.doubleclick.net/aclk?sa=L&ai=BhePvZEmoVoO0BMuo8gWx0aXADsHdlNcIAAAAEAEggbLFIDgAWLGAyIzPAmCJ68aE-BOyARB3d3cucnAtb25saW5lLmRlugEJZ2ZwX2ltYWdlyAEJ2gEYaHR0cDovL3d3dy5ycC1vbmxpbmUuZGUvmALsJ6kCFpO30p02sj7AAgLgAgDqAh8vNTc2Ni9vbXMucnAtb25saW5lLmRlL2hvbWVwYWdl-AL00R6QA-wJmAOMBqgDAeAEAZAGAaAGINgHAA&num=0&cid=5GhC3iR6yJvejkDhO_tlihee&sig=AOD64_2LYTQVb515nUTa4Hzx6j470osgpQ&client=ca-pub-8974942827941932&adurl=http://servedby.flashtalking.com/click/2/56791;1591664;1271766;211;0/?ft_impID=29488FD71E8E69&g=294862F8F4A692&random=663540047&ft_width=200&ft_height=600&url=8305416","clickTag1":"https://adclick.g.doubleclick.net/aclk?sa=L&ai=BhePvZEmoVoO0BMuo8gWx0aXADsHdlNcIAAAAEAEggbLFIDgAWLGAyIzPAmCJ68aE-BOyARB3d3cucnAtb25saW5lLmRlugEJZ2ZwX2ltYWdlyAEJ2gEYaHR0cDovL3d3dy5ycC1vbmxpbmUuZGUvmALsJ6kCFpO30p02sj7AAgLgAgDqAh8vNTc2Ni9vbXMucnAtb25saW5lLmRlL2hvbWVwYWdl-AL00R6QA-wJmAOMBqgDAeAEAZAGAaAGINgHAA&num=0&cid=5GhC3iR6yJvejkDhO_tlihee&sig=AOD64_2LYTQVb515nUTa4Hzx6j470osgpQ&client=ca-pub-8974942827941932&adurl=http://servedby.flashtalking.com/click/2/56791;1591664;1271766;211;0/?ft_impID=29488FD71E8E69&g=294862F8F4A692&random=311191593&ft_width=200&ft_height=600&url=8305416"},"ftReturn":"","guid":"294862F8F4A692","ftConfID":"0","ftTimestamp":"1453869413","ftKeyword":"","ftSegmentList":[],"ftSegment":"","serveDom":"http://cdn.flashtalking.com","ftServeDom":"http://cdn.flashtalking.com","mvt":false,"ftMVT":false,"siteName":"OMSDE","campaignID":"56791","placementDescription":"v0102CPMronprivatkreditWallpaperSkyxxxxxxxxxxxxxx","cID":"53858","creativeID":"1271766","pID":"1591664","divID":"ftdiv1591664","adVis":1,"ftGeoCountry":"jp","ftGeoState":"14","ftGeoCity":"foocity","ftGeoISP":"jupiter telecommunication co. ltd","ftGeoSpeed":"broadband","ftDMA":"-1","ftLong":"1.00","ftLat":"1.00","ftPostal":"111-1111"}


Searching for scroll related javaScript doesn't really help. It seems that all Ads providers in this page come with JavaScript for controlling the scrolling.


Mike, do you have an idea where the culprit is hidding?



On Contacting them:

The twitter account is not a good way to reach them out.
Maybe this email address: mediaberatung(at)rheinische-post.de
or maybe the contact listed on the right side of 
http://www.rp-media.de/online/technische-spezifikationen.html
who are handling the ads budget and might have contacts with the technical teams.

Comment 4

[Karl Dubost💡 :karlcow]

oops forgotten to ni mike on previous comment. Comment #3

Comment 5

[Karl Dubost💡 :karlcow]

Ah maybe my comment #3 here is more for Bug 1238504 ?
Then this one is about? 

Ah probably about #wrapper > header

<header class="waypoint-check-top sticky" style="top: -118px; margin-left: 0px;">
…
</header>


#wrapper header.sticky {
	position: fixed;
	left: auto;
}


Maybe: 
http://bc02.rp-online.de/asset-dist/rpo-standard-page-layout/main.js?20160114180800 


  if (!isMobileOrTablet) {
    $(window).bind('scrollstart', function () {
    });
    var d = 0;
    $(window).scroll(function () {
      var a = $(document).scrollLeft();
      d != a && (d = a, $('.sticky').margin({
        left: - a
      }))
    })

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

Karl, this seems stuck, can you help unstuck it?

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Bug 1246290 is the backup plan here. See https://bugzilla.mozilla.org/show_bug.cgi?id=1246290#c23

Comment 8

[Karl Dubost💡 :karlcow]

Brad, Kats,

do you mean unstuck by trying to reach out the owner of the site?
If yes, what would be the recommend approach to fix it.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Not necessarily. Unstuck just means figuring out what the next step here is and who is responsible for taking it. It looks like the needinfo on miket has been sitting a while, but you seem to have identified some code in comment 5 that might be the culprit. Do we need to verify that's the code responsible, or is the next step to find a recommended approach?

Comment 10

[Mike Taylor [:miketaylr]]

Ah, sorry for leaving this in needinfo? hell.

@Karl, your analysis in Comment #5 is good. 

The site can do something like this to fix the issue:

#wrapper header.sticky {
  position: fixed;
  position: sticky;
  left: auto;
}

Browsers that support position: sticky will do the right thing, and their existing strategy will work for browsers that don't.

Comment 11

[Adam Stevenson [:adamopenweb]]

I reached out to the contacts Karl suggested.

"the contact listed on the right side of 
http://www.rp-media.de/online/technische-spezifikationen.html
who are handling the ads budget and might have contacts with the technical teams."

Comment 12

[Adam Stevenson [:adamopenweb]]

Response from our contact:

"Hi Adam,

thank you for your mail to us. We will discuss the situation in our team and if we fix it with your recommended CSS-Fix in our website.

Kind regards, "

Comment 14

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

Platform triage meeting decision: We are waiting for a fix from the website on this one.

Comment 15

[Petruta Horea [:phorea], Desktop Test Engineering]

I can't reproduce this on Nightly 49.0a1 2016-05-25 under Win 10 64-bit, default settings or APZ disabled per page (apz.disable_for_scroll_linked_effects - True).

Reporter, do you still see this? Thanks!

Comment 16

[arni2033]

I still see it with default settings. Disabling APZ for scroll linked effects fixes it, yes.
That site always loads different advertisements, so I only checked the header. Its position is updated
after a short delay, just like 5 month ago. The following steps are probably more obvious and correct.

STR_3:
0. Set mouse option "When I rotate mouse wheel" to "scroll by 1 page"
1. Open http://www.rp-online.de/, wait until it's loaded
2. Hover mouse over one of the sections in the header, e.g. section "KULTUR"  [huge panel will appear]
3. Rotate mouse wheel down once
4. Rotate mouse wheel up once

AR:  The header together with the panel update their position after a short delay (0.1-0.5 second)
     As a result, they promptly disappear after Step 3, but then appear again. I.e. blink
ER:  No blinking; header and panel should move smoothly on the screen, at least like in non-e10s.

Comment 17

[Botond Ballo [:botond]]

(In reply to arni2033 from comment #16)
> 0. Set mouse option "When I rotate mouse wheel" to "scroll by 1 page"

Where is this setting?

Comment 18

[arni2033]

(In reply to Botond Ballo [:botond] from comment #17)
> (In reply to arni2033 from comment #16)
> > 0. Set mouse option "When I rotate mouse wheel" to "scroll by 1 page"
> Where is this setting?
http://windows.microsoft.com/en-us/windows/change-mouse-settings#1TC=windows-7

Comment 19

[Botond Ballo [:botond]]

(In reply to arni2033 from comment #18)
> (In reply to Botond Ballo [:botond] from comment #17)
> > (In reply to arni2033 from comment #16)
> > > 0. Set mouse option "When I rotate mouse wheel" to "scroll by 1 page"
> > Where is this setting?
> http://windows.microsoft.com/en-us/windows/change-mouse-settings#1TC=windows-
> 7

Ah, thanks; I didn't realize this was a Windows-specific issue.

Comment 20

[arni2033]

(In reply to Botond Ballo [:botond] from comment #19)
> Ah, thanks; I didn't realize this was a Windows-specific issue.
It was never said that it was Windows-specific. I suppose you tested all operating systems and only reproduced this on Windows before setting OS -> Windows, right?

Comment 21

[Botond Ballo [:botond]]

(In reply to arni2033 from comment #20)
> It was never said that it was Windows-specific. I suppose you tested all
> operating systems and only reproduced this on Windows before setting OS ->
> Windows, right?

Well, the STR is Windows-specific. I'm not sure what I would test on other OSes.

Comment 22

[arni2033]

(In reply to Botond Ballo [:botond] from comment #21)
> Well, the STR is Windows-specific.
OK, skip Step 0: I just reproduced this with that option set to unusual to me "Scroll by 3 lines".
> I'm not sure what I would test on other OSes.
Literally, anything. Just open that site and try to find a bug, that's a universal algorithm.

Comment 23

[Botond Ballo [:botond]]

You're right, this issue is not specific to Windows. Scrolling a larger amount per wheel tick just makes the issues more noticeable (and there are probably ways to configure the mouse to scroll by 1 page per tick on other platforms too). Sorry for the noise.

The underlying issue is the evangelism issue reported to the site in comment 11 (switching between position:fixed and position:absolute instead of using position:sticky), for which we are still waiting for a response.

Comment 24

[Mike Taylor [:miketaylr]]

arni2033, would you be able to test if this is still an issue? I'm not sure how to configure a mac to reproduce, thanks!

Comment 25

[arni2033]

There's no need to set non-standard configuration of browser or OS to reproduce - read comments 21-23

This is reproducible on:   Win7_64, Nightly 50, 32bit, ID 20160627030215
I won't test this bug anymore as it's so insignificant compared to other bugs I filed, e.g. bug1257815

Also, I don't know why I even reported this as is. I currently encounter the same bug on dozens of sites, and that's russian sites along (mostly). Yes, I have a list. The only thing that could help this
Firefox issue (Not a bug of the site. It's a bug in Firefox, and that's exactly how I reported it originally) is setting pref "apz.disable_for_scroll_linked_effects" to "true" by default.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Mike, do we need to follow-up with the site here?

Comment 27

[Mike Taylor [:miketaylr]]

I spoke with Adam Stevenson about this a few days ago -- he was going to attempt re-contact again, since it appears nothing has changed.

Comment 28

[Adam Stevenson [:adamopenweb]]

I sent another message to our contact to get an update on this issue.

Comment 29

[Adam Stevenson [:adamopenweb]]

Still no response from our contact at rp-digital.de.

Comment 30

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to keywords.

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:karlcow, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 32

[Oana Arbuzov [:oanaarbuzov]]

I've checked the issue, but for me hovering "KULTUR" category (or any other top bar category) does not open any panel.
If I scroll down and back, the header does not disappear and the scrolling is smooth. While scrolling down/up, the ad on the right side, blinks but it does not influence the header.

Tested with:
Browser / Version: Firefox Nightly 101.0a1 (2022-04-07)
Operating System: Windows 10 Pro

Botond does the issue still reproduce on your side?

Comment 33

[Botond Ballo [:botond]]

I believe the issue remains valid as filed. The site stills use a scroll-linked effect (changing the site header between position:relative and position:fixed in response to scroll events), and we emit a console warning about this, and as a result the transition of the header lags slightly behind scrolling.

The suggestion to update the site to use position:sticky is still relevant. In addition, scroll-linked animations, currently under development, will provide a richer set of options for website authors to express these types of transition effects.

Comment 34

[Raul Bucata]

I was able to reproduce the issue.

Tested with:

Browser / Version: Firefox Nightly 110.0a1 (2023-01-12) (64-bit)
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome.

Comment 35

[Dennis Schubert [:denschub]]

Based on comment 33, this seems to be perf-related? Moving it to the performance triage component for y'all to decide.

Comment 36

[Greg Mierzwinski [:sparky]]

:botond, is this issue still reproducible with the site mentioned in comment 0?

Comment 37

[Botond Ballo [:botond]]

(In reply to Greg Mierzwinski [:sparky] from comment #36)

:botond, is this issue still reproducible with the site mentioned in comment 0?

It looks to me like the site has changed since the time the bug was filed:

• The header is now already position: fixed when the page loads, and remains position: fixed after you scroll down.
• There is no more console warning about a scroll-linked effect.
• The header does decrease in size when you scroll down and increase in size when you scroll back up. These changes are implemented in script and there is a delay between the start of the scroll and the change to the header. (This means the effect is still technically a "scroll-linked effect", even though it might not be one that our detector catches and warns about.)
  • However, the same behaviour is observable in Chrome.
  • The site could improve this in the future by using scroll-driven animations. (This feature is not yet enabled by default in all browsers.)

Since our behaviour on the current site is now comparable to Chrome, I would suggest closing this issue as "invalid".

Comment 38

[Julien Wajsberg [:julienw]]

Sounds good, thanks!