638369 - URL bar is slow to populate

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Dietrich Ayala (:dietrich)]

I've noticed lately that at startup, the main browser UI will be visible but nothing is in the URL bar. It stays like that for up to a few seconds, and then the URL bar populates and the page starts to render.

If the title/URL is available, can we pre-load it into the front-end earlier in the process?

That would allow the user to know what's actually going on. Currently I'm always sitting and waiting, curious to what Fennec is trying to load. If the title or URL was pre-loaded, I could hit stop. Or at least be aware of what's going on.

Comment 1

[Matt Brubeck (:mbrubeck)]

Bug 611327 fixed this for some cases, but not for the URL that's loaded at startup.

Comment 2

[Matt Brubeck (:mbrubeck)]

Attachment: patch

Update the titlebar immediately when a new tab is created.  (Note: We can't do this within the Tab constructor or Tab.create, because it won't work until Browser.selectedTab is updated.)

Comment 3

[Matt Brubeck (:mbrubeck)]

Requesting to land this for Fennec 4.0.  It is a significant polish issue (essentially the same as bug 611327 which was blocking-fennec:2.0+) and most importantly it improves our perceived startup speed.

The patch is one line and low risk.

Comment 4

[Wesley Johnston (:wesj)]

Comment on attachment 516969 [details] [diff] [review]
patch

Wish we could just make this method "public".

Comment 5

[Stuart Parmenter]

Can we add a comment to say that this sets it to the url?

Comment 6

[Matt Brubeck (:mbrubeck)]

Attachment: patch v2

(In reply to comment #5)
> Can we add a comment to say that this sets it to the url?

Done

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 517593 [details] [diff] [review]
patch v2

Why not do this here:
http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser-ui.js#880

Comment 8

[Matt Brubeck (:mbrubeck)]

(In reply to comment #7)
> Why not do this here:
> http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser-ui.js#880

That code isn't called on TabOpen for the very first tab - we don't add the event listener until the UIReadyDelayed event, which happens when the first tab is already loaded.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 517593 [details] [diff] [review]
patch v2

Fine. We can take this for now, but I'd like a bug filed to fix this in general.

Comment 10

[Matt Brubeck (:mbrubeck)]

http://hg.mozilla.org/mobile-browser/rev/ee3ee8a6e83b

Filed followup bug 639962.

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

so this patch sets the URLbar to "about:home" during startup, right?

Comment 12

[Wesley Johnston (:wesj)]

It isn't shown due to: 

http://mxr.mozilla.org/mobile-browser/source/chrome/content/Util.js#129

Comment 13

[Matt Brubeck (:mbrubeck)]

That's right - the effect during startup is that the "Enter Search or Address" hint is shown right away, instead of appearing a moment later.

Comment 14

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #13)
> That's right - the effect during startup is that the "Enter Search or Address"
> hint is shown right away, instead of appearing a moment later.

Seems like a long round-about way to get the editbox placeholder to show in the URLBar

Comment 15

[Matt Brubeck (:mbrubeck)]

(In reply to comment #14)
> Seems like a long round-about way to get the editbox placeholder to show in the
> URLBar

That's just a nice side effect.  The more noticeable effect is when launching Fennec via a link from another app.  Now the titlebar shows the URL of the loading page immediately, instead of remaining blank (often for several seconds).

Comment 16

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #15)
> (In reply to comment #14)
> > Seems like a long round-about way to get the editbox placeholder to show in the
> > URLBar
> 
> That's just a nice side effect.  The more noticeable effect is when launching
> Fennec via a link from another app.  Now the titlebar shows the URL of the
> loading page immediately, instead of remaining blank (often for several
> seconds).

Fine, I'll hold off my rant to back this out.

Comment 17

[Matt Brubeck (:mbrubeck)]

Backed out for Ts regression:
http://hg.mozilla.org/mobile-browser/rev/f57a75b80dca

Comment 18

[Matt Brubeck (:mbrubeck)]

Attachment: patch v3

In my local testing on device, the code added by this patch seems to take only 1 millisecond to run.  Pushing to Try to see if this still regresses ts:
http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=3d3b834503b8

Comment 19

[Matt Brubeck (:mbrubeck)]

Comment on attachment 555592 [details] [diff] [review]
patch v3

Try did not show a Ts regression from this patch:
http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=3d3b834503b8

Comment 20

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/40eedacb461c

Comment 21

[Ed Morley [:emorley]]

http://hg.mozilla.org/mozilla-central/rev/40eedacb461c

Comment 22

[Cristian Nicolae (:xti)]

Verified fixed on:
Mozilla/5.0 (Android;Linux armv7l;rv:9.0a1)Gecko/20110906
Firefox/9.0a1 Fennec/9.0a1
Device: Samsung Galaxy S
OS: Android 2.2