531071 - bypass the awesomescreen when the browser is being opened for specific page

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Madhava Enros [:madhava]]

The new start page behaviour is that the browser opens the awesomescreen.  This makes sense when the user is opening the browser, but when the browser is being opened to go to a specific page, we should bypass that screen and show the page.  Examples:

- the browser launches because the user has clicked on a link on another app
- the browser is restarted because of a add-on installation, and the add-on has a first-run page

I ran into this first with weave, for which there is a bug here:  Bug 530857

Comment 1

[Ed Lee :Mardak]

http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#680
bringFront == true should trigger the autocomplete edit popup to close

Comment 2

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

I think BrowserUI.newTab(...) might be a better method for Weave to call. It already does some UI manipulation. I can patch it to handle closing the awesomebar too.

Comment 3

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

Attachment: patch

This patch adds a method to close the autocomplete panel, since we have two ways to close it and neither is very explicit in its use.

The patch also closes the autocomplete panel if adding a new, non-blank tab

Comment 4

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

pushed:
https://hg.mozilla.org/mobile-browser/rev/f834bf77d59b

Comment 5

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

Unfortunately, there is a race condition. Since both Fennec and the add-on are using "onload" to load the firstrun page, the add-on can actually beat Fennec to adding the first page. If that happens, Fennec will still show the awesomebar over the add-on's firstrun.

I think in addition the the first patch, we need an event to fire after we finish the Fennec firstrun code. The add-on can use the event to know it's ok to show their firstrun page.

Comment 6

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

Attachment: patch (fire event)

This additional patch fires a UIReady event after Fennec opens the initial tab and shows the autocomplete UI. This should be enough to allow add-ons to show there own firstrun pages using BrowserUI.newTab

Comment 7

[Ed Lee :Mardak]

It seems like the UIReady event can be sent before the add-on even starts executing its script, so the add-on might never run if it's keyed on the event.

Comment 8

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

(In reply to comment #7)
> It seems like the UIReady event can be sent before the add-on even starts
> executing its script, so the add-on might never run if it's keyed on the event.

window.addEventListener("UIReady", doFirstRun, false);

That should work, right?

Comment 9

[Ed Lee :Mardak]

Oh nevermind. It was waiting for load before executing, so I suppose I can just change the load event listener to a UIReady event listener.

Comment 10

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

Great!

pushed:
https://hg.mozilla.org/mobile-browser/rev/1d1b9c70d423

Comment 11

[Aakash Desai [:aakashd]]

verified FIXED on builds:
Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2b5pre) Gecko/20091204 Firefox/3.6b5pre Fennec/1.0b6pre

and

Mozilla/5.0 (X11; U; Linux armv6l; Nokia N8xx; en-US; rv:1.9.3a1pre) Gecko/20091204 Firefox/3.7a1pre Fennec/1.0b5