This is a fully reproducable bug, which only occurs on trunk builds. When the -turbo tray icon comes back (after closing a browser window), if you immediatley doubleclick it, Navigator will open, but the URLbar won't display the current page, nor will AutoComplete function. Browsing still works though.

FYI, I'm on 2002052508, however this is on all recent trunk builds.

I am seeing this on 2002052809 trunk build also (mozilla)

This is dependant on the fix of Bug 146340 and was created in the resolution of Bug 98673, as the -turbo icon now flashes out.

*** Bug 149333 has been marked as a duplicate of this bug. ***

It sounds like there's some timing problem here that was not taken care of by the semaphores when full shutdown and restart were done. I wonder if my original patch for bug 98673 (the one that was called too "Rube Goldberg-ish") would have avoided this problem -- that patch didn't need semaphores but instead delayed the restart to the last possible moment.

This problem actually sounds pretty serious if we are going to enable turbo mode by default. Although it would not be normal for a user to immediately click on the icon as soon as he shuts down the last window, that scenario might occur if he closed the window down by mistake. Let me add that the symptoms are more serious than described in the bug description. I observered that browser does not respond to any url's typed in the url bar. That is, you can type there and then press ENTER, but nothing happens. The only way you can get to another page is by clicking on a link or by typing the url into file->open-web-location. Nominating for nsbeta1

nsbeta1+/ADT2

might be a dup of bug 82534

Not exactly the same. In bug 82534, you cannot type at all. In this case you can type into the URL bar, but you can't visit the page that you typed in. Also this bug is very reproducible whereas that other one isn't.

*** Bug 146992 has been marked as a duplicate of this bug. ***

OK, here's a dirty patch that will solve the problem. What it does is waits for five seconds after relaunching the turbo browser before it allows you to double click on the icon. If you click too soon, your click will be ignored. Ideally the test should not be time based but rather event based. That is, there must be some event which has not yet happened when the icon is double-clicked, and the lacking of that event is what is causing the problem with the url bar. If we could figure out what that event was, we could come up with a much cleaner patch. But this patch is better than nothing because it does fix the problem and has practically a zero risk of regression.

Bill Law and I just discovered that this is not a turbo issue. The same problem will occur if you click on a mozilla icon twice in succession. However we do have a patch for the turbo case only. And it involves an event rather than a timeout. Attaching new patch next.

Comment on attachment 87405 [details] [diff] [review] patch based on an event occuring r=law (provided an appropriate comment is added)

Comment on attachment 87408 [details] [diff] [review] event-based patch but including comments r=law

We noticed that the same problem can be reproduced without using QuickLaunch. If you double click on a Mozilla program icon twice in fairly quick succession, then one of the windows will open with this problem. That is harder to fix because we don't have a reliable way of detecting that the initial window load has not completed (we infer that in the fix for this bug from the fact that OnLastWindowClosing has been called). One possibility might be to hook into the notification that goes out to hide the splash screen. That happens fairly late in the loading of the initial window (just before it is shown). That solution may not work on all platforms, depending on how they handle the splash screen.

Comment on attachment 87408 [details] [diff] [review] event-based patch but including comments sr=darin

-> morse

Regarding the patch for the original QuickLaunch problem, I would suggest we provide some way of showing through UI that the browser is not accessable (e.g. put a red 'X' over the icon for three seconds, in addition to simply disabling double clicks and right click/Navigator, which seems like a messy workaround to me) for the time being.

adding adt1.0.1+. Please get drivers approval and then check into the branch.

SharkDaddy, see bug 151532 which addresses the issue you just raised.

Fix has been checked in on the trunk. Awaiting driver's approval for branch checkin.

Excellent, that's much more professional looking IMO. Thanks for pointing it out Stephen.

Comment on attachment 87408 [details] [diff] [review] event-based patch but including comments Please land this on the 1.0.1 branch. Once there, replace the "mozilla1.0.1+" keyword with the "fixed1.0.1" keyword.

verified on branch 20020628

verified on trunk build also 2002062804

*** Bug 130915 has been marked as a duplicate of this bug. ***