158030 - URL bar and Bookmarks tab are not getting initialized if a browser pops up on startup when "Master Password" dlg is in effect.

Status: RESOLVED WORKSFORME

(Toolkit :: Password Manager, defect)

Description

[Aleksey Nogin]

This is a weird bug that I've been seing on several machines running various
versions of Red Hat Linux running various trunk nighties over at least last 6
months (probably more). I still see it in BuildID 2002071713 (trunk).

Basically, I have my preferences set up to start MailNews&Browser on Mozilla
startup and often the Browser window will come "underinitialized".

"Good" startup sequence ("expected"):
1) Mail window pops up
2) "Master Password" window pops up (I have several IMAP & NNTP accounts set to
"check mail on startup").
3) Start up process gets suspended until the password is typed.
4) Once I type the password, the browser window comes up (and works normally).

"Bad" startup sequence ("actual" in some percentage of startups):
1) Mail window pops up.
2) "Master Password" pops up
3) Right away the Browser window pop up
4) I type the master password, the browser window finishes loading and I see
that the following is broken (screenshot coming):
  a) Bookmarks sidebar tab says "This tab is not available right now."
(switching to another tab and back fixes it).
  b) URL bar is empty (the bookmark icon is there, but the URL is not) and
non-functional - I can type in there, but if I press "Enter" after having typed
a URL, it just reloads the current (e.g. startup) URL completely ignoring what
I've typed. 

If I open a new browser window, everything works there but there is no way to
fix (b) in the original window (so I end up having to close it).

With most Mozilla builds (BuildID 2002071713, for example), the "bad" scenario
seems somewhat rare, but with some (such as BuildID 2002070712) almost all
startups hit the "bad" scenario.

Also, if the "Master Password" dlg comes up with no text field (as described in
bug 101403), then I always get the "bad" scenario.

Comment 1

[Aleksey Nogin]

Attachment: Screenshot.

Comment 2

[Aleksey Nogin]

P.S. Possibly related bugs (but please do not be too quick to mark as a dup):
bug 82534 and bug 103197.

Comment 3

[Dimitrios]

Agree, better leave 82534 alone. Probably there won't be a good chance to fix
this one if duplicated against that cluttered bug.

Comment 4

[David Hyatt]

--> default owner.

Comment 5

[Aleksey Nogin]

Related to 90337? BTW, I no longer see this in most recent builds (but it may be
just because I am using a faster machine now)...

Comment 6

[OstGote!]

looks like related to bug 74331, bug 150006, bug 223491, bug 289996

Comment 7

[Nickolay_Ponomarev]

There have been many changes, in particular related to modal dialogs, which could have fixed this bug. In any case, this component is probably not right for the bug...

Comment 8

[Ian Neal]

This should probably live under toolkit password manager as that is where the code lives (I think).

Comment 9

[Matthew N. [:MattN]]

Fairly sure this doesn't happen anymore. Reopen if I'm wrong.