Open Bug 1327666 Opened 7 years ago Updated 2 years ago

[e10s] scroll position isn't remembered when I switch tabs

Categories

(Firefox :: General, defect)

defect

Tracking

()

REOPENED

People

(Reporter: arni2033, Unassigned)

References

Details

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Set about:preferences as home page to work around bug 1208208 and bug 1208222 and bug 1193291
2. Open url   data:text/html,<style>body{height:10000px}   , scroll the page to the center
3. Press Alt+Home, then Alt+Left

AR:  Scroll position is lost
ER:  Should be preserved
No longer blocks: 1277113
Component: Untriaged → Session Restore
Component: Session Restore → Tabbed Browser
Summary: [e10s] scroll position isn't restored/preserved when I navigate to parent process → [e10s] scroll position isn't remembered when I switch tabs
AIUI, this is either a session store or docshell bug, as they're the only things that muck with scroll positions, AIUI. We use session store to switch from remote to non-remote docshells (which would be happening here) so I would expect this to be an issue with session restore. Mike, can you clarify?
Component: Tabbed Browser → Untriaged
Flags: needinfo?(mdeboer)
Redirecting to other Mike, because he's in-the-know wrt remote flippin'.
Flags: needinfo?(mdeboer) → needinfo?(mconley)
Mossop has graciously offered to take some needinfo / reviews off of my plate, so redirecting to him!
Flags: needinfo?(mconley) → needinfo?(dtownsend)
As far as I can tell this is only reproducible with data: uris. It seems likely that session store is the problem but restarting the browser restores the scroll position correctly. So that's confusing. Without debugging in more I don't really have much idea why this might be happening and since it only happens in rare cases I'm not sure it is worth looking at that deeply. Is there a more common way to reproduce that I'm missing?
Flags: needinfo?(dtownsend)
(In reply to Dave Townsend [:mossop] from comment #4)
> Is there a more common way to reproduce that I'm missing?

I don't know, but I suspect it's a race of sorts. I'll have a look when I can.
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Dave Townsend [:mossop] from comment #4)
> As far as I can tell this is only reproducible with data: uris. It seems
> likely that session store is the problem but restarting the browser restores
> the scroll position correctly. So that's confusing. Without debugging in
> more I don't really have much idea why this might be happening and since it
> only happens in rare cases I'm not sure it is worth looking at that deeply.
> Is there a more common way to reproduce that I'm missing?

Odd. I can reproduce with just about any page. I tried e.g. https://www.gijsk.com/blog/ and scrolled down a lot, then clicked the home button, then clicked back. Same problem. Tested on OS X, current nightly. Are you seeing something else?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(dtownsend)
(In reply to :Gijs from comment #6)
> (In reply to Dave Townsend [:mossop] from comment #4)
> > As far as I can tell this is only reproducible with data: uris. It seems
> > likely that session store is the problem but restarting the browser restores
> > the scroll position correctly. So that's confusing. Without debugging in
> > more I don't really have much idea why this might be happening and since it
> > only happens in rare cases I'm not sure it is worth looking at that deeply.
> > Is there a more common way to reproduce that I'm missing?
> 
> Odd. I can reproduce with just about any page. I tried e.g.
> https://www.gijsk.com/blog/ and scrolled down a lot, then clicked the home
> button, then clicked back. Same problem. Tested on OS X, current nightly.
> Are you seeing something else?

I could have sworn I was seeing something different last week, but now I am not.
Flags: needinfo?(dtownsend)
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0 (20170223030204)

I have tested the issue on latest FF release (51.0.1) and latest Nightly build and could not reproduce it. Currently the scroll position is preserved when going back and forth to the page. 
Marking this as Resolved: Works For Me. If anyone can still reproduce it, feel free to reopen it.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
I can still trivially reproduce. Not sure why you can't. Did you make sure e10s is enabled?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Yes, the e10s is set to true for me on Nightly.

I was able to reproduce the issue on latest Nightly and Firefox (51.0.1) with any page only if my home page is explicitly set to about:preferences. If my homepage is set to about:newtab the issue is not reproducible for me.

I think the correct component is Core:Layout (similar to 1286179). I could not set the component (it's missing for me).
(In reply to Stefan [:StefanG_QA] from comment #10)
> Yes, the e10s is set to true for me on Nightly.
> 
> I was able to reproduce the issue on latest Nightly and Firefox (51.0.1)
> with any page only if my home page is explicitly set to about:preferences.
> If my homepage is set to about:newtab the issue is not reproducible for me.

STR (on current nightly on OS X):

1. open data:text/html,<style>body{height:10000px} 
2. scroll down really far;
3. in the location bar, type: "about:preferences" and hit enter, wait for it to load;
4. click the back button.

> I think the correct component is Core:Layout (similar to 1286179). I could
> not set the component (it's missing for me).

Interesting. Maybe :kats has an idea.
Flags: needinfo?(bugmail)
(In reply to :Gijs from comment #11)
> > I think the correct component is Core:Layout (similar to 1286179). I could
> > not set the component (it's missing for me).
> 
> Interesting. Maybe :kats has an idea.

Hm, I can reproduce this on OS X Nightly with and without APZ enabled. We've had a number of scroll-restoration-fails bugs lately because of APZ but since this one happens without APZ it probably has a different root cause. I ran with gdb attached and it seems like when we go back to the page, we never even get a call to the ScrollToImpl function in nsGfxScrollFrame.cpp. That seems to imply it's not a layout-side issue but more likely in session restore or something else higher up that's not even trying to restore the scroll position. I might be wrong, though.

I also noticed that with dom.ipc.processCount=2 (the default on nightly) the process holding the data: URL dies when you go to about:preferences and a new one is created when you go back. This was screwing up my attempt at gdb-breakpointing so I did it with dom.ipc.processCount=1, which behaved the way I would expect.
Flags: needinfo?(bugmail)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #12)
> (In reply to :Gijs from comment #11)
> > > I think the correct component is Core:Layout (similar to 1286179). I could
> > > not set the component (it's missing for me).
> > 
> > Interesting. Maybe :kats has an idea.
> 
> Hm, I can reproduce this on OS X Nightly with and without APZ enabled. We've
> had a number of scroll-restoration-fails bugs lately because of APZ but
> since this one happens without APZ it probably has a different root cause. I
> ran with gdb attached and it seems like when we go back to the page, we
> never even get a call to the ScrollToImpl function in nsGfxScrollFrame.cpp.
> That seems to imply it's not a layout-side issue but more likely in session
> restore or something else higher up that's not even trying to restore the
> scroll position. I might be wrong, though.
> 
> I also noticed that with dom.ipc.processCount=2 (the default on nightly) the
> process holding the data: URL dies when you go to about:preferences and a
> new one is created when you go back. This was screwing up my attempt at
> gdb-breakpointing so I did it with dom.ipc.processCount=1, which behaved the
> way I would expect.

Sorry, for "the way I would expect", do you mean the process didn't die and/or gdb breakpointing worked, or do you mean the scroll position also got restored correctly? :-)
Flags: needinfo?(bugmail)
This similar to bug 1216385.
(In reply to :Gijs from comment #13)
> Sorry, for "the way I would expect", do you mean the process didn't die
> and/or gdb breakpointing worked, or do you mean the scroll position also got
> restored correctly? :-)

Whoops, sorry for being unclear. I meant the process didn't die and gdb breakpointing worked. The scroll position was still not restored properly.
Flags: needinfo?(bugmail)
The issue is still reproducible on latest Nightly (20170320030209). 
I will set the component to General as other similar scrolling issues.
Component: Untriaged → General
Update: Issue is not reproducible with e10s = false on latest Nightly nor on Firefox release.
Mike,

if I open a new tab with the data URI and scroll it down, and then I use SessionStore.getTabState(gBrowser.selectedTab), it produces:

"{"entries":[{"url":"data:text/html,<style>body{height:10000px}","charset":"","ID":2,"docshellUUID":"{ae0ec9bf-6e7b-aa45-a97f-1df8527ae730}","triggeringPrincipal_b64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","principalToInherit_base64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","triggeringPrincipal_base64":"SmIS26zLEdO3ZQBgsLbOywAAAAAAAAAAwAAAAAAAAEY=","docIdentifier":2,"persist":true}],"lastAccessed":1490215710302,"hidden":false,"attributes":{},"userContextId":0,"index":1,"userTypedValue":"data:text/html,<style>body{height:10000px} ","userTypedClear":0,"scroll":{"scroll":"0,5976"},"image":null,"iconLoadingPrincipal":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA"}"

if I then navigate to about:preferences, I get:

"{"entries":[{"url":"data:text/html,<style>body{height:10000px}","charset":"","ID":4157033673,"docshellUUID":"{fe4eba6f-d708-ca4b-af62-87f33c501052}","triggeringPrincipal_b64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","principalToInherit_base64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","triggeringPrincipal_base64":"SmIS26zLEdO3ZQBgsLbOywAAAAAAAAAAwAAAAAAAAEY=","docIdentifier":222,"persist":true},{"url":"about:preferences","title":"Preferences","charset":"","ID":223,"docshellUUID":"{fe4eba6f-d708-ca4b-af62-87f33c501052}","originalURI":"about:preferences","triggeringPrincipal_b64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","principalToInherit_base64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","triggeringPrincipal_base64":"SmIS26zLEdO3ZQBgsLbOywAAAAAAAAAAwAAAAAAAAEY=","docIdentifier":223,"structuredCloneState":"AgAAAAAA8f8LAAAABAD//3AAYQBuAGUARwBlAG4AZQByAGEAbAAAAA==","structuredCloneVersion":8,"persist":true}],"lastAccessed":1490215720142,"hidden":false,"attributes":{},"userContextId":0,"index":2,"userTypedValue":"data:text/html,<style>body{height:10000px} ","userTypedClear":0,"image":"chrome://browser/skin/preferences/in-content/favicon.ico","iconLoadingPrincipal":"SmIS26zLEdO3ZQBgsLbOywAAAAAAAAAAwAAAAAAAAEY="}"

Note that the scroll information seems to have disappeared from the entry information. Is that expected? I guess so, because if I go back, scroll down again, then go to a random web URL (that would load in the same process), I get:

"{"entries":[{"url":"data:text/html,<style>body{height:10000px}","charset":"","ID":4157096300,"docshellUUID":"{3de38e51-9b99-b648-856d-6cd7573ee60c}","triggeringPrincipal_b64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","principalToInherit_base64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","triggeringPrincipal_base64":"SmIS26zLEdO3ZQBgsLbOywAAAAAAAAAAwAAAAAAAAEY=","docIdentifier":4,"persist":true},{"url":"https://gijsk.com/","title":"Gijs > Home","charset":"UTF-8","ID":15,"docshellUUID":"{3de38e51-9b99-b648-856d-6cd7573ee60c}","originalURI":"http://gijsk.com/","loadReplace":true,"triggeringPrincipal_b64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","principalToInherit_base64":"vQZuXxRvRHKDMXv9BbHtkAAAAAAAAAAAwAAAAAAAAEYAAAAA","triggeringPrincipal_base64":"SmIS26zLEdO3ZQBgsLbOywAAAAAAAAAAwAAAAAAAAEY=","docIdentifier":15,"persist":true}],"lastAccessed":1490215945702,"hidden":false,"attributes":{},"userContextId":0,"index":2,"userTypedValue":"data:text/html,<style>body{height:10000px} ","userTypedClear":0,"image":"https://gijsk.com/favicon.ico","iconLoadingPrincipal":"ZT4OTT7kRfqycpfCC8AeuAAAAAAAAAAAwAAAAAAAAEYB3pRy0IA0EdOTmQAQS6D9QJIHOlRteE8wkTq4cYEyCMYAAAAC/////wAAAbsBAAAAEmh0dHBzOi8vZ2lqc2suY29tLwAAAAAAAAAFAAAACAAAAAkAAAAI/////wAAAAj/////AAAACAAAAAkAAAARAAAAAQAAABEAAAABAAAAEQAAAAEAAAASAAAAAAAAABL/////AAAAAP////8AAAAR/////wAAABH/////AQAAAAAAAAAAAAEAAAAAAAA="}"

where it's also missing. However, in that case, if I hit the back button the scroll position *is* restored. What code's responsible for that, and does it not use the entries list?
Flags: needinfo?(mdeboer)
I think all this will be properly fixed by bug 1265818 - excellent work going on there.
Flags: needinfo?(mdeboer)
Depends on: 1265818
The issue is still reproducible on Firefox 57.0.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.