1056443 - [e10s] Location bar goes blank when loading a page

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[(no longer active)]

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.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This happens when we switch between remote and non-remote tabs. It should go away when we stop doing that.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(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?

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: patch

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.

Comment 5

[Tim Taubert [:ttaubert] (inactive)]

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!

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/22d78dbf4b3a

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/22d78dbf4b3a

Comment 8

[Cornel Ionce [:noni] [Hubs QA]]

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.