Closed Bug 531071 Opened 10 years ago Closed 10 years ago
bypass the awesomescreen when the browser is being opened for specific page
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
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.
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+
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 → ---
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 ago → 10 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.