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)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

REOPENED

People

(Reporter: thee.chicago.wolf, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

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
Neil says mcsmurf also mentioned seeing this.
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).
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.
Does this also happen with Firefox?
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.
Has anyone been able to trace the regression to any specific change?
Well, Bug 839891 implement tab preview and so it kinda caused this regression.
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.
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
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Setting browser.taskbar.previews.enable=false also fixes the issue I reported in bug 970993.
Arthur K: would you be able to check if the same problem(s) happen with Firefox?
Firefox 29 is ok. I tested before with 25b4 and it was ok so it appears to be affecting SM only.
Still present on SM 2.26.1.
Still present on SM 2.29b1.
Still present on SM 2.30 and 2.31b.
Still present on SM 2.32b2.
Still present on SM 2.33.1.
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).
(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.
Still present on 2.39 contrib build 20151021030937.
(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 ...").
Still present on 2.46 contrib build 20160904185344.
Hello, 

I confirm this bug.

Same problem with the pop-up windows.
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.
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?

SM isn't likely to ever get brought back to life so pointless to keep this open.

Status: REOPENED → RESOLVED
Closed: 11 years ago5 years ago
Resolution: --- → WONTFIX

Valid bug so do not close this.

Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Attachment #9387090 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: