Closed Bug 531071 Opened 10 years ago Closed 10 years ago

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

Categories

(Firefox for Android Graveyard :: General, defect)

Fennec 1.1
x86
macOS
defect
Not set

Tracking

(fennec1.0+)

VERIFIED FIXED
fennec1.0
Tracking Status
fennec 1.0+ ---

People

(Reporter: madhava, Assigned: mfinkle)

References

Details

Attachments

(2 files)

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
Flags: wanted-fennec1.0?
Blocks: 530857
tracking-fennec: --- → ?
http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#680
bringFront == true should trigger the autocomplete edit popup to close
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.
Attached patch patchSplinter Review
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
Assignee: nobody → mark.finkle
Attachment #414896 - Flags: review?(gavin.sharp)
Attachment #414896 - Flags: review?(gavin.sharp) → review+
pushed:
https://hg.mozilla.org/mobile-browser/rev/f834bf77d59b
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Post-B5
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
tracking-fennec: ? → 1.0+
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
Attachment #415897 - Flags: review?(gavin.sharp)
Attachment #415897 - Flags: review?(gavin.sharp) → review+
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.
(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?
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.
Great!

pushed:
https://hg.mozilla.org/mobile-browser/rev/1d1b9c70d423
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.