Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090722 Minefield/3.6a1pre After opening the All Tabs panel it cannot be closed anymore. Also hovering or clicking thumbnails doesn't result in a reaction. The whole panel stucks while I'm able to work with Minefield in the background. With the current behavior the panel is not usable and you have to close the browser to be able to use Minefield normally again. Steps: * Click All tabs button in the tabbar or show all tabs inside the Ctrl-Tab panel if more then 7 tabs are open.

The steps to reproduce seem a bit too vague.

What is too vague by clicking the All Tabs button or "show all xx tabs" inside the Ctrl-Tab panel?

I can't reproduce it this way, and haven't heard from others that they encountered something similar.

I tested it again on Windows and it seems like to be an OS X only bug. Works fine with WinXP.

Note that Neil Deakin reviewed the patch, and I'm pretty sure he did that on OS X...

(In reply to comment #5) > Note that Neil Deakin reviewed the patch, and I'm pretty sure he did that on OS > X... And that means there can't be a regression? I doubt so. More precise steps: 1. Open All Tabs panel (tabbar or button inside the Ctrl-Tab panel) 2. Click at any position (thumbnail, x button) After step 2 the panel doesn't close and hangs around in the foreground.

(In reply to comment #6) > (In reply to comment #5) > > Note that Neil Deakin reviewed the patch, and I'm pretty sure he did that on OS > > X... > > And that means there can't be a regression? I doubt so. That means that there's more to it than "open the All Tabs panel on OS X". In any case, this doesn't seem to be a tabbed browser bug. Pushing off to widget land.

Reasking for blocking1.9.2 because the all tabs panel is not usable on os x.

I don't think this needs to block just because of All Tabs, as that's currently pref'ed off. However, the underlying core bug might be block-worthy.

Attachment 389942 [details] doesn't seem to show what bug 469774 is about. Being unable to close the application is also not part of bug 469774. Bug 469774 is purely visual.

(In reply to comment #11) > Being unable to close the application is also not part of bug 469774. s/application/panel/

In my impression the panel is closed but is still shown. That's why I can click through. It's similar to bug 505658 which you have duped against bug 469774. If you feel its not related we should undupe 505658 and dupe this bug against bug 505658.

What I see from debugging is that the preview <button> is focused when it is clicked, and then an <input> is immediately focused (I think this is the autocomplete widget). The <input> is focused with the FLAG_NOSCROLL flag (and only that flag) which should narrow down what's doing this. The only case like this might be the popuphiding event in the previews listener. Could the alltabs popup possibly be attempting to be hidden and then something either cancels the popuphiding event, or causes an error which prevents something from happening?

Henrik, is there anything suspicious in your error console? Attachment 346858 [details] nicely illustrate what bug 469774 is about. Attachment 389942 [details] is very different.

No. Sadly I don't see any error in the Error Console. With the attachments it's clear now. Thanks! We should undupe and handle it separately.

So, can you interact with the panel or can you not interact with the panel? Do you try to close it manually? It's not clear to me why you made bug 505658 a duplicate of this one.

I can only click once. Clicking on the close button the panel is still visible and doesn't react on further events. Same happens when clicking the thumbnails. When you move the window around the panel follows the window. You have to close the window to get rid off the panel. All those items gave me the impression that bug 505658 should be a dupe of this bug and not bug 469774. But I have reask the reporter.

Are you able to use the search field? Do the hover effects work when moving the mouse over the previews? > Same happens when clicking the thumbnails. Is there no response at all or is the expected tab selected? > When you move the window around the panel follows the window. Now *this* sounds like bug 469774. But again, attachment 389942 [details] shows the panel outside of the window's bounds. Bug 469774 also wouldn't make it possible to open the Quit dialog behind the panel.

This bug is very recent. Here's the regression range: firefox-2009-07-20-03-mozilla-central firefox-2009-07-21-03-mozilla-central Presumably this implicates the patch for bug 465076.

(In reply to comment #20) > Are you able to use the search field? Do the hover effects work when moving the > mouse over the previews? The search field works as long as you don't click onto the panel. Same applies to the hover effect. > > Same happens when clicking the thumbnails. > > Is there no response at all or is the expected tab selected? No response. No tab is changed and the focus is placed to the location bar.

Enn, does this mean that you're seeing this bug? (In reply to comment #14) > What I see from debugging is that the preview <button> is focused when it is > clicked, and then an <input> is immediately focused (I think this is the > autocomplete widget). The <input> is focused with the FLAG_NOSCROLL flag (and > only that flag) which should narrow down what's doing this. [...]

Does this fix it? https://build.mozilla.org/tryserver-builds/dgottwald@mozilla.com-try-b855c4fd5020/try-b855c4fd5020-macosx.dmg

It does.

I think this makes closing the panels less snappy, so if there's a way to fix the underlying bug here as well as in bug 506513, I'd like to undo this...

Comment on attachment 390714 [details] [diff] [review] front-end patch (checked in) http://hg.mozilla.org/mozilla-central/rev/fc412c73605b Not sure if this bug should be closed. Maybe it should be investigated why this happened only on Mac?

See comment 21 why this is a regression. Adding back regression keyword. Is there a way to test this with an automated test?

See the Product and Component fields and comment 27 for why this is not a regression, based on the information we have so far.