User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042606 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042606 Minefield/3.0pre Entering a password in a bookmark loaded in the sidebar prompts the old remember password dialog instead of the new unobtrusive bar at the top. Reproducible: Always Steps to Reproduce: 1.Bookmarks > Organize bookmarks 2.Organize > New Bookmark 3.Enter a page that requires login (e.x., http://www.facebook.com/presence/popout.php) 4.Visit bookmark 5.Submit login information Actual Results: See old remember password popup dialog Expected Results: See the new remember password banner at top of sidebar
Hmm, the sidebar is a bit of an oddball, so I'l not too surprised this doesn't work. Other notification bars also don't work there (eg, load cnn.com there and you don't get the popup-blocked bar). The superficial cause is probably due to the hackish way we map a content window to a <tabbrowser>. See nsLoginManagerPrompter.js :: _getNotifyBox(). Instead of just window -> browser -> tabbrowser, we could also look for window -> browser -> sidebar. But it's kind of sucky to force every everyone to remember the sidebar as a special case. :( There's also the question if notification bars are the right thing to use in the sidebar (because it's usually so narrow), but I suppose since we're using them everywhere else (eg, addons manager) it would be consistent.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Vista → All
Hardware: PC → All
Version: unspecified → Trunk
(In reply to comment #1) > There's also the question if notification bars are the right thing to use in > the sidebar (because it's usually so narrow), but I suppose since we're using > them everywhere else (eg, addons manager) it would be consistent. Actually we have a special narrow notification bar for that :-)
inIDOMUtils.getParentForNode(this._window.top.document).parentNode ... although if that's not a hack then I don't know what is ;-)
It looks as if we really need an API on nsXULDocument that wraps nsDocument::FindContentForSubDocument.
Aha, I've found an API that works: _window.top.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIWebNavigation).QueryInterface(Components.interfaces.nsIDocShell).chromeEventHandler.parentNode although you should check that chromeEventHandler is actually a node first.
Actually the top is unnecessary as subframes inherit the chrome event handler.
2 years ago
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.