Open
Bug 921874
Opened 11 years ago
Updated 2 months ago
Closing an active browser session via close [x] in aero peek opens instead a blank window and closing that blank window continues to open a blank window endlessly
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
REOPENED
People
(Reporter: thee.chicago.wolf, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
666.50 KB,
application/octet-string
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 (Beta/Release) Build ID: 20130916112225 Steps to reproduce: I have any two (or more) browser windows open to any web page. I use Aero peek to bring up the active browser windows and attempt to close them via the close [X] button in the top right corner of the peek window (see attached video). Actual results: Instead of closing the browser window, it brings up a blank browser window similar to doing an about:blank (see attached video). You can click as many times you want on the close [X] button in peek but it will endlessly open a blank page as if it is stuck in a loop. If you bring the browser window up full screen you can close it via the close button in the top right corner and it will close normally so something wonky is happening only in peek Expected results: It should close the browser window and not open a blank page.
Present on trunk, confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: SeaMonkey 2.21 Branch → Trunk
Comment 2•11 years ago
|
||
Neil says mcsmurf also mentioned seeing this.
Comment 3•11 years ago
|
||
Neil said in Bug 839891 Comment 25 that the X is vor closing tabs, not windows. But I agree with this bug here that the X should close tabs AND windows (so close the window if it's the last tab).
Reporter | ||
Comment 4•11 years ago
|
||
Hmm, but I am wondering if this is just referring to the previews that appear when the mouse cursor is hovering over an open tab on the tab bar and not the Windows task bar below? I don't agree too much with Bug 839891 Comment 25 because of the fact that Aero peek's close button [X] should close down a window or active application/session, not a tab per se.
Comment 5•11 years ago
|
||
Does this also happen with Firefox?
Reporter | ||
Comment 6•11 years ago
|
||
Not seeing it on 25.0b4.
I can confirm this bug on both Win7 X64 and Win8 X64. Furthermore this bug has only appeared ( at least for certain on Win8 )with 2.21 release. Prior to the upgrade to 2.21 the close button worked as expected and closed the window. Even if this new behavior is intentional it is still a serious usability regression and should be either reverted or at the very least have an about:config option to bring back the older style "closes window" button.
Doing a little more digging through the other bug report https://bugzilla.mozilla.org/show_bug.cgi?id=839891#c25 I found that setting browser.taskbar.previews.enable=false in about:config restores the prior behavior as a workaround. This setting should be false by default to preserve the long standing behavior that users have come to expect when closing through the Aero Peek feature of the taskbar.
Reporter | ||
Comment 9•11 years ago
|
||
Has anyone been able to trace the regression to any specific change?
Comment 10•11 years ago
|
||
Well, Bug 839891 implement tab preview and so it kinda caused this regression.
Reporter | ||
Comment 11•11 years ago
|
||
Well, I am not sure what happened but this bug appears to be fixed and the only thing that changed recently on my system was a bunch of non-WU Hotfixes I put on. I am going to see if I can figure out which Hotfix "fixed" it or if it was a fluke.
Reporter | ||
Comment 12•11 years ago
|
||
Well, in this case, it doesn't seem to be related to a hotfix. Tried with SM 2.19 and then 2.23 and it works. Perhaps the site author updated the SWF file that runs the test to a newer version or something. WFM on XP SP3 and WIn 7 X64 SP1.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Updated•11 years ago
|
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 13•11 years ago
|
||
Apologies for the churn and for accidentally closing this bug. Comment 12 was intended for bug 830200 and not this bug. After testing with the hotfixes I applied to my home machine, I tried on another unpatched machine I still see the issue. I will try to uninstall each hotfix one at a time on my home machine until I figure out what changed.
Reporter | ||
Comment 15•10 years ago
|
||
Setting browser.taskbar.previews.enable=false also fixes the issue I reported in bug 970993.
Comment 16•10 years ago
|
||
Arthur K: would you be able to check if the same problem(s) happen with Firefox?
Reporter | ||
Comment 17•10 years ago
|
||
Firefox 29 is ok. I tested before with 25b4 and it was ok so it appears to be affecting SM only.
Reporter | ||
Comment 18•10 years ago
|
||
Still present on SM 2.26.1.
Reporter | ||
Comment 19•10 years ago
|
||
Still present on SM 2.29b1.
Reporter | ||
Comment 20•10 years ago
|
||
Still present on SM 2.30 and 2.31b.
Reporter | ||
Comment 21•10 years ago
|
||
Still present on SM 2.32b2.
Reporter | ||
Comment 22•9 years ago
|
||
Still present on SM 2.33.1.
Comment 23•9 years ago
|
||
Did this trick solve your problem ? Try setting browser.taskbar.previews.enable in about:config to false. If not ..... my bug 973206 is not a duplicate of this one (your bug).
Reporter | ||
Comment 24•9 years ago
|
||
(In reply to Raymond from comment #23) > Did this trick solve your problem ? > Try setting browser.taskbar.previews.enable in about:config to false. > If not ..... my bug 973206 is not a duplicate of this one (your bug). I thought I tried this setting once before and reported that it works and exhibits the expected behavior. For posterity, browser.taskbar.previews.enable=false fixes the problem.
Reporter | ||
Comment 25•9 years ago
|
||
Still present in contrib builds of SM 2.35 (https://l10n.mozilla-community.org/~akalla/unofficial/seamonkey/nightly/latest-comm-release-windows32/) and contrib builds of 2.37a/2.38a (http://seamonkey.callek.net/contrib/).
Reporter | ||
Comment 26•9 years ago
|
||
Still present in contrib builds of SM 2.37 (https://l10n.mozilla-community.org/~akalla/unofficial/seamonkey/nightly/latest-comm-release-windows32/) and 2.38b.
Reporter | ||
Comment 27•9 years ago
|
||
Still present on 2.39 contrib build 20151021030937.
Comment 28•9 years ago
|
||
(In reply to JHauman from comment #8) > I found that setting browser.taskbar.previews.enable=false in about:config restores the prior > behaviour as a workaround. Extremely useful information; thank you. This bug has been driving me crazy ever since I upgraded from 2.17.1 (sticking at 2.38 for now, as 2.39 appears regressive w.r.t. "allow this site ...").
Reporter | ||
Comment 29•8 years ago
|
||
Still present on 2.46 contrib build 20160904185344.
Comment 30•7 years ago
|
||
Hello, I confirm this bug. Same problem with the pop-up windows.
Reporter | ||
Comment 31•7 years ago
|
||
This seems to be *almost* fixed in 2.53 builds. What I am seeing is that you can now close active windows via Aero peek close button ([X]) save for the very last active window.
Reporter | ||
Comment 32•7 years ago
|
||
In testing a newer build from FRG, it's not quite "better" as was before so still seems borked. At this point, might it not be best to just flip pref browser.taskbar.previews.enable=false and call it a day?
Reporter | ||
Comment 33•5 years ago
|
||
SM isn't likely to ever get brought back to life so pointless to keep this open.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 5 years ago
Resolution: --- → WONTFIX
Comment 34•5 years ago
|
||
Valid bug so do not close this.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment hidden (spam) |
Updated•2 months ago
|
Attachment #9387090 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•