|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
40 bytes, text/x-review-board-request
|Details | Review|
192.43 KB, image/png
2.07 MB, video/webm
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.
Note that I'm reasonably sure this is e10s only.
tracking-e10s: --- → ?
Summary: Possible for docShell to be confused about which document is loaded if initial content restore is aborted → [e10s] Possible for docShell to be confused about which document is loaded if initial content restore is aborted
Created attachment 8690164 [details] MozReview Request: Bug 1226657 - Regression test Bug 1226657 - Regression test
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
Created attachment 8690193 [details] 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)
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.
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?
(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
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
Created attachment 8693061 [details] 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)
Yes, alright, let's keep this open.
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?
>>> 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])
You need to log in before you can comment on or make changes to this bug.