Closed Bug 1056443 Opened 8 years ago Closed 7 years ago
[e10s] Location bar goes blank when loading a page
STR: Type a URL in the location bar, and press enter. The URL bar first goes blank (and the placeholder text shows up), and then after a few seconds the URL pops in back to the location bar, usually along when there is something to paint on the page, or at least when we set the title. So this might be a delay until we get a response from the network on the request, or something.
Summary: Location bar goes blank when loading a page → [e10s] Location bar goes blank when loading a page
This happens when we switch between remote and non-remote tabs. It should go away when we stop doing that.
Depends on: 999239
(In reply to Bill McCloskey (:billm) from comment #1) > This happens when we switch between remote and non-remote tabs. It should go > away when we stop doing that. I think bug 999239 didn't do that. What's the plan for this now?
No longer depends on: 999239
Flags: qe-verify? → qe-verify+
This happens when we switch processes and run the LoadInOtherProcess session store code. Assume we're navigating from about:newtab to foo.com. The sequence is as follows: - Start to restore. We send history data down to child. However, the history data only includes about:newtab. The foo.com URL is in loadArguments, which we haven't sent down yet. - The content process calls setCurrentURI while restoring the history. The URL it passes in is about:newtab. That triggers an onLocationChange message which causes the URL bar to show about:newtab. - We immediately start to restore tab content. This time we send down loadArguments. However, before doing anything, we setCurrentURI(about:blank). This triggers another onLocationChange, which blanks out the URL bar. - Eventually the correct URL loads and we get an onLocationChange for it. So this is why we flash about:newtab, and then the URL bar is blank for most of the load. I think the simplest solution is to avoid the two setCurrentURI calls when loadArguments is non-null.
Assignee: nobody → wmccloskey
Status: NEW → ASSIGNED
Attachment #8592569 - Flags: review?(ttaubert)
Comment on attachment 8592569 [details] [diff] [review] patch Review of attachment 8592569 [details] [diff] [review]: ----------------------------------------------------------------- This whole remoteness switching is such a mess :/ I really hope we can get rid of this before shipping e10s... Thanks a lot for working on this though!
Attachment #8592569 - Flags: review?(ttaubert) → review+
Reproduced the issue on Windows 7 64-bit using 2014-08-20 Nightly (build ID: 20140820030202) with e10s enabled. Confirming the fix using latest Nightly, build ID: 20150419030206 on Windows 7 64-bit, Ubuntu 14.04 32-bit and Mac OS X 10.9.5.
You need to log in before you can comment on or make changes to this bug.