User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0 When I navigate through tabs that contain flash content firefox may loose the focus. My guess is that the bug is Mac OS only with flash content running in window or transparent modes. Window mode being the default flash mode. I reproduce the bug on www.chatroulette.com (transparent mode) and www.pearltrees.com (window mode). I don't reproduce on youtube (opaque mode). Reproducible: Always Steps to Reproduce: 1. Open one tab on a random fully HTML page 2. Open one tab on www.chatroulette.com 3. Switch from the fully HTML tab to chatroulette tab. Actual Results: Firefox loses the focus. There are no more rollover effects on any Firefox component (current page as well). Expected Results: Firefox and the content displayed should keep the focus when going from tab to tab. We have a lot of these feedbacks coming from our community that run on Mac and just upgraded to Firefox 4.

I now reproduce on every mode. And you can reproduce it with any kind of page containing a flash embed. 1. Open one tab on a random fully HTML page 2. Open one tab with a flash embed 3. Give the flash the focus by clicking on it 4. Switch to the fully HTML tab 5. Switch to the tab containing the flash embed Firefox loses the focus. There are no more rollover effects on any Firefox component (current page as well). Reproduced on Firefox Mac. No problem on Windows.

Works for me on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.2a1pre) Gecko/20110406 Firefox/4.2a1pre Also, could you see if the issue occurs if using Firefox in safe mode: http://support.mozilla.com/kb/Safe+Mode How about with a new, empty testing profile? (Don't install any addons into it) http://support.mozilla.com/kb/Basic+Troubleshooting#w_8-make-a-new-profile

Reproduced in safe mode and with an empty profile.

Reporter, do you have anything new to add about this issue?

Nop, nothing new to add.

Setting resolution to Resolved WFM. Reporter, if you have anything new to add about this issue, feel free to reopen this bug

Vlad, why did you close this?

I can reproduce this. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110428 Firefox/6.0a1, 64 bit, HW acceleration on, Flash 10.2.153.1

Still works for me using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0a1) Gecko/20110501 Firefox/6.0a1 Please provide a screenshot of the problem.

The problem is that the window no longer receives mouse move events and thus doesn't show any mouseover feedback. It's an interactivity problem and not something you can see on a screenshot.

Markus, I'm not completely clear how you are "switching to tab". We have several different methods: * click the tab * keyboard shortcut * List All Tabs button * Switch-to-Tab in the Awesomebar Can you please be as specific as possible with your steps to reproduce? Thanks

I reproduced it by clicking on the tab. Here are more precise steps to reproduce: 1. From the tab with this bugzilla page, open a new tab with http://www.adobe.com/products/flashplayer/ , for example by middle-clicking this link 2. Switch to that tab (doesn't matter how). 3. Click into the flash object at the top (the one saying "Deliver breakthrough web experiences across screens" at the moment). 4. Switch back to this bugzilla tab by clicking the tab. 5. Switch again to the flash tab by clicking the tab. 6. Move your mouse over the refresh button, or a tab, or a bookmarks button, or anything else that should give visible feedback on mouseover. Now all mouseover feedback is broken until you click anywhere on the window again. (We always need a ChildView to be the window's firstResponder, otherwise we won't receive mouse move events. I suspect that something has made the NSWindow itself firstResponder, but I haven't debugged it yet.)

I'm not able to reproduce this given your steps in comment 12. I'm basically using the same configuration as you reported in comment 8. The only difference being that I'm using Flash 10.2.152.26 whereas you are using Flash 10.2.153.1. I'll try updating my flash version to see if that reproduces this bug. If it does, we may have a Flash bug here.

It's not a Flash bug. I'm able to reproduce it even with my (very plain-vanilla) Debug Events Plugin from bug 441880. I'm currently tracking down the regression range (it's a recent regression). I'll have more to say later today.

Thanks Steve. FYI, I've updated to version 10.2.159.1 of Flash and am still unable to reproduce this bug.

I've found the regression range: firefox-2011-03-01-03-mozilla-central firefox-2011-03-02-03-mozilla-central The only plugin-specific patch in that range is my patch for bug 627649. So I'll bet that's what caused/triggered this bug :-( Roc has already suggested what may be a better way to fix 627649. That may help with this bug, and maybe also bug 649021.

Thanks Steve. Adding regression keyword.

This is probably a plugins bug. Though I'll keep in mind what you say, Markus, about the possibility that the firstResponder isn't a ChildView object.

moving tracking to 5 because this is a regression from 4 and might warrant some further attention.

Touching plug-in code this late in the 5 cycle scares us. Would love this addressed sooner rather than later on mozilla-central.

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.