Closed
Bug 519099
Opened 15 years ago
Closed 15 years ago
Location bar stops working and does not allow any input. Restarts does not help
Categories
(Firefox :: Session Restore, defect, P2)
Tracking
()
VERIFIED
FIXED
Firefox 3.7a1
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta2-fixed |
blocking1.9.1 | --- | .6+ |
status1.9.1 | --- | .6-fixed |
People
(Reporter: bugzilla, Assigned: zpao)
References
Details
(Keywords: regression, verified1.9.1, verified1.9.2)
Attachments
(1 file)
1.21 KB,
patch
|
zeniko
:
review+
dveditz
:
approval1.9.1.6+
|
Details | Diff | Splinter Review |
Build ID:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090926 Minefield/3.7a1pre
STEPS TO REPRODUCE
1. Make sure you have "Show my windows and tabs from last time" enabled
2. Go to http://www.chromeexperiments.com/detail/monster/
3. Click on "Launch Experiment"
4. Close the main window, leaving the popup as the only window open
5. Exit Firefox
6. Restart Firefox
7. It will not be possible to type anything in the Location bar
ADDITIONAL INFO
You wont be able to type anything into the Location bar now, restarting Firefox wont help. Creating a new tab will not help either.
Only way to get out of this "locked" mode is to open a new window
Tested on Windows and could not reproduce, MAC OS X only?
Flags: blocking-firefox3.6?
Reporter | ||
Updated•15 years ago
|
Summary: Location bar does not allow any input under certain conditions → Location bar stops working and does not allow any input. Restarts does not help
Comment 1•15 years ago
|
||
Cannot reproduce on Linux build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090928 Minefield/3.7a1pre
Comment 3•15 years ago
|
||
I can reproduce on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090928 Minefield/3.7a1pre.
Comment 4•15 years ago
|
||
denying blocking until there's independent verification.
reporter: can you please try to reproduce this in safe mode?
http://support.mozilla.com/en-US/kb/Safe+Mode
Flags: blocking-firefox3.6? → blocking-firefox3.6-
Keywords: qawanted
Comment 5•15 years ago
|
||
Flags: blocking-firefox3.6- → blocking-firefox3.6?
Comment 6•15 years ago
|
||
The location bar's readonly and isempty attributes are "true", even after restart, but I don't see where these atts are persisted.
Comment 7•15 years ago
|
||
I can not reproduce this on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20090928 Minefield/3.7a1pre
However, I'm not sure what the reporter refers to in step 1; have "Show my windows and tabs from last time" enabled. There is a shutdown dialog similar to that when more than one window or tab is open. Step 4 ensures that dialog won't appear. I can not reproduce this with multiple tabs/windows open nor with only the popup only.
Comment 8•15 years ago
|
||
(In reply to comment #7)
> However, I'm not sure what the reporter refers to in step 1; have "Show my
> windows and tabs from last time" enabled.
Minefield > Preferences > General tab > When Minefield starts: Show my windows and tabs from last time
Comment 9•15 years ago
|
||
ah, yes, I forgot about that one. I can reproduce as reported with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20090928 Minefield/3.7a1pre
Comment 10•15 years ago
|
||
blocking. can we get a regression range?
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Comment 11•15 years ago
|
||
Looking at the resulting sessionstore.js, the isPopup property of the page is true, which sets the location bar to readonly on restore:
http://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/src/nsSessionStore.js#2366
Flags: blocking-firefox3.6+ → blocking-firefox3.6?
Comment 12•15 years ago
|
||
The location bar of the popup that opens after step 3 in comment 0 is readonly, so it makes sense that when the window is restored it remains readonly, no?
Comment 13•15 years ago
|
||
Can not repro on XP. With the difference in they way Mac and XP do Window?Menu handling. On XP with the popup being menuless, restarting minefield opens the popup and the last window closed (one with main menu). That window's location bar is functional.
Comment 14•15 years ago
|
||
On mac the behavior changed between 7/23 and 7/28 on mozilla central. I'll narrow it down a little further.
Comment 15•15 years ago
|
||
Assignee | ||
Comment 16•15 years ago
|
||
So I actually think this is expected behavior right now... Starting with bug 481090 we special cased OSX to not be too tricky. Things did get a bit hairier after I landed bug 394759.
This would be the guilty changeset: http://hg.mozilla.org/mozilla-central/rev/9b8f46d71e4e - which means it should also be causing problems currently with Firefox 3.5 :(
We're explicitly disabling the location bar on restore for popups. The location bar is disabled before shutdown too, so it shouldn't be _that_ surprising.
Moving to sessionstore where this fits better.
Component: Location Bar and Autocomplete → Session Restore
QA Contact: location.bar → session.restore
Comment 17•15 years ago
|
||
(In reply to comment #16)
>
> This would be the guilty changeset:
> http://hg.mozilla.org/mozilla-central/rev/9b8f46d71e4e - which means it should
> also be causing problems currently with Firefox 3.5 :(
>
Yes, it is on 3.5
Comment 18•15 years ago
|
||
(In reply to comment #16)
> We're explicitly disabling the location bar on restore for popups. The location
> bar is disabled before shutdown too, so it shouldn't be _that_ surprising.
>
It's unexpected because on restart it is not a popup window that is opened. What is opened is a browser window which happens to have broken location bar.
Comment 19•15 years ago
|
||
This reminds me of a bug around Firefox 3.5 time, although in that case there was a workaround - see bug 495495. Re-marking as P2 blocker (flag was removed in error)
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Priority: -- → P2
Comment 20•15 years ago
|
||
Is this a session restore issue, or is it an issue with places code (and the location bar)?
Updated•15 years ago
|
Assignee: nobody → paul
Assignee | ||
Comment 21•15 years ago
|
||
Ok, so what's the expected behavior then? If we're restoring a popup window, do we just turn that into a normal window? Or do we essentially backout bug 481090?
Also, I assume then that if we make the window normal, we ignore the other window features that we try to restore ("menubar", "toolbar", "locationbar", "personalbar", "statusbar", "scrollbars")? (Ignore the fact that scrollbars doesn't actually behave correctly, see bug 485955)
Comment 22•15 years ago
|
||
(In reply to comment #21)
> Ok, so what's the expected behavior then?
In comment 13 Tracy says that on Windows a "real" window is always restored; the popup + the final real window are both restored, even if the popup was actually the final window.
Assignee | ||
Comment 23•15 years ago
|
||
(In reply to comment #22)
> In comment 13 Tracy says that on Windows a "real" window is always restored;
> the popup + the final real window are both restored, even if the popup was
> actually the final window.
Indeed. But we specifically disabled that on OSX in bug
481090.
Assignee | ||
Comment 24•15 years ago
|
||
limi: "the tl;dr summary: there are some fundamental issues with how we do this that should be fixed in the next release — in the meantime: restore the window, but un-gimp it when it's restored, so if people start using it as a normal window, it behaves like one"
Assignee | ||
Comment 25•15 years ago
|
||
So I was a little wrong in my diagnosis before. It's a combination of things that didn't consider this edge case.
On startup we do ignore (ie. don't hide) all features for the first window that were hidden on shutdown (eg. location bar). This was good enough. On quit we always made sure the first window wasn't a popup. Then came bug 481090 which changed that on OS X. This was still ok though because even if the window had .isPopup, we were still enabling all features. Then bug 495495 ensured that if .isPopup we explicitly disabled the location bar again.
So there's a 1 line fix to remove isPopup at startup. However this doesn't affect Private Browsing mode. So if there was only a popup with location bar disabled going into PB, the popup will be restored with the location bar disabled. I think that's ok and probably closer to what the user expects. This is the better fix in my opinion.
I could make the fix more complicated and clear hidden/isPopup at shutdown for OSX or in _getCurrentState (but that's a change that would impact consumers of the API). I don't really want to do either of these.
Assignee | ||
Comment 26•15 years ago
|
||
Takes approach 1 from previous comment.
Attachment #406468 -
Flags: review?(zeniko)
Comment 27•15 years ago
|
||
Comment on attachment 406468 [details] [diff] [review]
Patch v0.1
r+=me with thanks.
Attachment #406468 -
Flags: review?(zeniko) → review+
Assignee | ||
Comment 28•15 years ago
|
||
Pushed http://hg.mozilla.org/mozilla-central/rev/a6273493eab4
and http://hg.mozilla.org/releases/mozilla-1.9.2/rev/467098ec0cb9
Asking for blocking on 1.9.1 since this is a regression on that branch (starting with 1.9.1.2) - regression landed here: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8cbe12f3a208
Status: NEW → RESOLVED
blocking1.9.1: --- → ?
Closed: 15 years ago
status1.9.2:
--- → final-fixed
Keywords: regression
Resolution: --- → FIXED
Assignee | ||
Comment 29•15 years ago
|
||
We'll need a litmus test for this since it's only in the startup path.
Flags: in-litmus?
Comment 30•15 years ago
|
||
If this is the patch you want to land please request approval1.9.1.5 on it. Otherwise create the back-port and request approval on that.
Updated•15 years ago
|
Target Milestone: --- → Firefox 3.7a1
Assignee | ||
Comment 31•15 years ago
|
||
Comment on attachment 406468 [details] [diff] [review]
Patch v0.1
Patch applies cleanly to 1.9.1 (and more importantly, works). No backport necessary.
Attachment #406468 -
Flags: approval1.9.1.5?
Comment 32•15 years ago
|
||
Comment on attachment 406468 [details] [diff] [review]
Patch v0.1
Approved for 1.9.1.5, a=dveditz for release-drivers
Attachment #406468 -
Flags: approval1.9.1.5? → approval1.9.1.5+
Updated•15 years ago
|
Flags: in-testsuite-
Assignee | ||
Comment 33•15 years ago
|
||
Reporter | ||
Comment 34•15 years ago
|
||
Will this also land on the Firefox 3.6 branch?
Assignee | ||
Comment 35•15 years ago
|
||
(In reply to comment #34)
> Will this also land on the Firefox 3.6 branch?
It has. http://hg.mozilla.org/releases/mozilla-1.9.2/rev/467098ec0cb9 (mentioned in comment #28). It landed after the beta, so if you're still seeing the problem, that would be why. It should be fixed in nightlies though.
Comment 36•15 years ago
|
||
verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091103 Minefield/3.7a1pre
Status: RESOLVED → VERIFIED
Comment 37•15 years ago
|
||
Verified fixed on 1.9.2 and 1.9.1 with
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b3pre) Gecko/20091109 Namoroka/3.6b3pre ID:20091109035432
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.6pre) Gecko/20091108 Shiretoko/3.5.6pre ID:20091108030959
Keywords: verified1.9.1,
verified1.9.2
Comment 38•15 years ago
|
||
3 test cases added:
https://litmus.mozilla.org/show_test.cgi?id=11513
https://litmus.mozilla.org/show_test.cgi?id=11514
https://litmus.mozilla.org/show_test.cgi?id=11515
Marking in-litmus+
Flags: in-litmus? → in-litmus+
You need to log in
before you can comment on or make changes to this bug.
Description
•