The current remove/hide code for doorhanger notifications is spread around in a way that makes it hard to try to implement bug 700913. I based these changes off the way we handle doorhangers in PopupNotifications.jsm, and it should be easy to add persistence/timeout options on top of this patch. Basically, I decided that we should just maintain a single set of doorhangers for each tab, and then we can let one method in DoorHangerPopup (updatePopupForTab) handle showing/hiding these doorhangers as appropriate. I also moved the code that creates DoorHangers to DoorHangerPopup.addDoorHanger so that GeckoApp doesn't need to do as much.

Also, I removed unnecessary calls to removeAllDoorhangers() in Tab, since handleLocationChange takes care of those cases for us (although I need to double check about reload).

Comment on attachment 573441 [details] [diff] [review] patch >diff --git a/mobile/chrome/content/browser.js b/mobile/chrome/content/browser.js > doorhanger: { >- show: function(aMessage, aValue, aButtons, aTab) { >- // use the current tab if none is provided >- let tabID = aTab ? aTab : BrowserApp.selectedTab.id; >+ >+ show: function(aMessage, aValue, aButtons, aTabID) { One of the refactors I want to do is make the NativeWindow API use "Tab" objects and not the Tab.id". I think it feels more natural taht way. Internally, the API will send the ID over to Java, but we shouldn't need to force the JS side to deal with tabIDs. We can do that in a NativeWindow API refactor though. Nice cleanup

This depends on the patches from bug 698598 that were recently backed out, so I'm gonna wait until those re-land to land this.