1226657 - [e10s] Possible for docShell to be confused about which document is loaded if initial content restore is aborted

Status: REOPENED

(Firefox :: Session Restore, defect, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

STR (best performed on a slower machine with a slower network connection)

1. Copy any url
2. Start Nightly
3. Right click location bar and chose "Paste & Go"
   (Perform as early as possible after UI available)
4. Wait to load the page
5. Click Reload button

Actual Results:
Reloading (F5) loads about:home instead of current page

Expected Results:
Reloading (F5) should load current page


This presents exactly like bug 1213650, but seems to be much rarer. The conclusion that we came to in bug 1213650 is that bug 1175267 (which was originally identified as the regressing bug for bug 1213650) exacerbated a pre-existing problem, and made it more likely to occur.

This test is for the more unlikely (but still possible) case.

I've written a test case, which I'll attach to this bug.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Note that I'm reasonably sure this is e10s only.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Attachment: MozReview Request: Bug 1226657 - Regression test

Bug 1226657 - Regression test

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Mossop tells me that this might explain the following perma fail in our SDK tests: https://dxr.mozilla.org/mozilla-central/rev/a2f83cbe53ac4009afa4cb2b0b8f549289b23eeb/addon-sdk/source/test/addons/remote/main.js#74

Comment 4

[arni2033]

Attachment: screenshot 1 (arni2033) - Netmonitor logs when it happens.png

Wow, you really filed this. This is hard to reproduce so I think it should be low priority.
I usually reproduce this using a new profile + user.js with the following prefs:
>   user_pref("browser.shell.checkDefaultBrowser", 0);
>   user_pref("app.update.enabled",false);
>   user_pref("app.update.auto",false);
>   user_pref("browser.startup.homepage_override.mstone", "41.0.2");
NI / mail for screencast / more detailed STR (if the test won't be reliable enough)

Comment 5

[arni2033]

I often experience another e10s-issue that may be connected to this one (otherwise hide this comment)
 When I "paste-n-go" a site link in urlbar, and it starts loading, there's  0.5s  time interval
 when pressing Escape does nothing. It doesn't cancel the loading, like it should.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

I guess this should be RESOLVED WORKSFORME when the backout of bug 1175267 hits central. Alice0775, can you please confirm when you have a build?

Comment 7

[Alice0775 White]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #6)
> I guess this should be RESOLVED WORKSFORME when the backout of bug 1175267
> hits central. Alice0775, can you please confirm when you have a build?


I can confirm the problem(Bug 1228179 and Bug 1213650) is fixed on latest Nightly.

https://hg.mozilla.org/mozilla-central/rev/47b49b0d32360fab04b11ff9120970979c426911
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 ID:20151127030231

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Thank you!

Comment 9

[arni2033]

Attachment: screencast 1 - Netmonitor logs when it happens (Nightly 20151127030231).webm

First of all, I admit that "paste-and-go" menuitem operates differently from "Ctrl+V - Enter". 
So I shouldn't have participated in discussion in bug 1213650.

But THIS bug is still presented. I could tell it earlier, because I also tested a build before bug 1175267 was fixed. I hope you'll believe me with this screencast. It's rare, as noted in comment 0
(And also I saw 1-2 very similar issues, but I'm not going to discuss them for now)

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Yes, alright, let's keep this open.

Comment 11

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160210004006

I could not reproduce the issue on the latest Aurora 46 nor on the latest Nightly 47.

arni2033, are you still seeing this issue?

Comment 12

[arni2033]

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20160209030347
I just reproduced it.
It happens every 3rd attempt, probably because Nightly Firstrun page is cached. I think that it'd be covered better by some test, because it's hard to reproduce for normal people (intentionally)
NI me if you need detailed STR (actually, there're already comment 4 + attachment 8693061 [details])