Entering a password in a bookmark loaded in the sidebar prompts the old password dialog

NEW
Unassigned

Status

()

Toolkit
Password Manager
P5
normal
10 years ago
2 years ago

People

(Reporter: nathaniel, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
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

Comment 2

10 years ago
(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 :-)

Comment 3

10 years ago
inIDOMUtils.getParentForNode(this._window.top.document).parentNode
... although if that's not a hack then I don't know what is ;-)

Comment 4

10 years ago
It looks as if we really need an API on nsXULDocument that wraps nsDocument::FindContentForSubDocument.

Comment 5

10 years ago
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.
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit

Comment 6

10 years ago
Actually the top is unnecessary as subframes inherit the chrome event handler.
You need to log in before you can comment on or make changes to this bug.