User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b9) Gecko/20100101 Firefox/4.0b9 Im currently using firefox beta 9 on windows vista. I was chatting with a facebook friend using facebook chat on the main page. I noticed that everytime i enter text, everything is fine. But when the other person responds, the cursor stops putting in text. I than have to click off the screen and then click back in the chat menu. Reproducible: Always Steps to Reproduce: 1.Chat with someone on facebook 2.When the other person repies back, the cursor doesn't respond with text inputs. 3. Actual Results: I was chatting with friend in beta 9 of firefox. once the person responds back, the cursor doesn't let me put in text in the chat box. Expected Results: it should have continue on with text inputs.

marking new based on the dupe I don't have Facebook and i will never create an Account there. Someone else have to find the right component and a regression range

I've the same problem, but the cursor don't only stops on Facebook, it stops in every textbox (like Gmail, Hotmail, etc.) when You got a respond via Facebook chat...

My problem is solved... I cleared the cookies and history entries contains facebook, and it works now perfectly! Hope it helps You too! All the best, Balázs Csikós

(In reply to comment #6) > *** Bug 626875 has been marked as a duplicate of this bug. *** Sorry about the duplication of the bug... I searched for any relevant bugs but failed to turn any relevant results... I however can attest that this is a legitimate bug.

(In reply to comment #5) > My problem is solved... > I cleared the cookies and history entries contains facebook, and it works now > perfectly! > > Hope it helps You too! > > All the best, > Balázs Csikós You shouldn't have to delete the cookies and history. It should work with out having to do that. I pretty sure when the stable version comes out, the bug will be resolved. Or wait for the next beta.

(In reply to comment #8) > (In reply to comment #5) > > My problem is solved... > > I cleared the cookies and history entries contains facebook, and it works now > > perfectly! > > > > Hope it helps You too! > > > > All the best, > > Balázs Csikós > > You shouldn't have to delete the cookies and history. It should work with out > having to do that. I pretty sure when the stable version comes out, the bug > will be resolved. Or wait for the next beta. I'm running a fresh install of Windows 7, and installed the beta immediately... I should have no problems whatsoever concerning cookies and history.

I'm not sure what to do with this bug. 1) aakash, does this show up on input for b8/b9 frequently? 2) reporters, can you reproduce this with a new profile, or only with your existing profile? If your existing profile, would you be willing to send your places.sqlite file so that an engineer can look at it? (note that this will include personal data such as browsing history, bookmarks, and cookies) 3) Does anything show up in the error console which might give an indication of what actual error is happening?

Yeah, there's decent regression here on beta9. To look at a trend from 7/8/2010 (i.e. when beta 1 came out) till now: http://input.mozilla.com/en-US/search/?q=url%3A*+chat+facebook&product=firefox&version=&date_start=07%2F08%2F2010&date_end= To look at the issues reported in beta 9 related to "facebook" and "chat" with a URL attached to the issue: http://input.mozilla.com/en-US/search/?q=url%3A*+chat+facebook&product=firefox&version=4.0b9&date_start=07%2F08%2F2010&date_end=&sentiment=sad

I tried it with a clean profile, install and safe mode and this weird thing happens, also prevents to type into other boxes like search box and find box. Fx4.0b9 Gecko20100101 Windows NT5.1.

Facebook is a big enough piece of the pie that we need to dig into this. Adding qawanted.

symptoms described in the input feedback might link to editor changes that landed in the b8/b9 cycle... I type letters but they do not appear in the text box. If I close the chat and reopen it it works. Facebook does not act properly. Chat doesn't work I can't see my notifications, and there is only a partial feed. my facebook chat is messing up and it won't do it on any other browser. I have to refresh Facebook each time I get a new chat message for me to be able to input text. Whenever someone at facebook chats with me it takes the focus out of the browser I need to click on the browser again to continue working

CCing some QA folks here. I wasn't able to reproduce this, but we need to do so very soon if this is going to be addressed soon.

It seems, if You turn off "New message sound" in Facebbok chat will be the only solution now... It works for me...

(In reply to comment #16) > It seems, if You turn off "New message sound" in Facebbok chat will be the only > solution now... It works for me... How do you turn it on or off? I'm not that much proficient in Facebook-fu... :-)

(In reply to comment #17) > (In reply to comment #16) > > It seems, if You turn off "New message sound" in Facebbok chat will be the only > > solution now... It works for me... > > How do you turn it on or off? I'm not that much proficient in Facebook-fu... > :-) Open up the chat window on the bottom right, click options.

I still can't reproduce this... Can anybody reproduce this reliably?

Here is the list of bugs that I have fixed between beta 8 and beta 9, FWIW. <http://is.gd/KE8WQI> I'm going through the list now.

I'm reproducing this in nightlies on Vista SP2 with both Flashblock AND Test Pilot enabled. I'm reproducing this in b9 on XP SP3 with a clean profile. Using two different Facebook accounts, so it's not something account specific. Haven't tried flipping that around, ie haven't tried nightlies on the XP machine or beta channel on the Vista machine. I'll have time later tonight to try that and try and find a regression range, but if someone gets there before me that's fine ;)

Majken, does it mean it could be Test Pilot related? Does it also happen with Test Pilot disabled?

(In reply to comment #22) > Majken, does it mean it could be Test Pilot related? Does it also happen with > Test Pilot disabled? According to our conversation on IRC, it happens for her with both extensions enabled. Henrik, have you managed to reproduce this on trunk with those two add-ons enabled?

(In reply to comment #22) > Majken, does it mean it could be Test Pilot related? Does it also happen with > Test Pilot disabled? Both have to be enabled for me to reproduce on a nightly. It was happening on beta even with feedback disabled. Home again, going to test more!

Ok, going to be a bit spammy or I won't keep my thoughts straight. The bug doesn't entirely happen in Beta 8, but there is some behaviour going on. I can't type while the other person's message is sending/drawing, but when they're done I can type again. Branch has the same behaviour, though it feels not quite so laggy.

Should have included this, while typing that comment I did experience the part where it breaks all typing. FB message came in on another tab while I was typing here, I had to switch to another tab and back to finish that comment.

Progress! In the nightlies prior to Jan 16 have the problem with a clean profile, I haven't yet figured out the bottom limit. In this build Mozilla/5.0 (Windows NT 6.0; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre the problem doesn't happen on a clean profile, and that odd delay while someone else's message is sent doesn't happen, either. Problem still exhibits in this build with Flashblock AND Test Pilot installed. During testing this problem was only happening intermittently on b9 on the xp machine (I left that one open to send test messages to myself, so it seems to be getting...better... the longer the window is open) I also had someone else with Windows 7 test - he used a nightly with the 2 extensions installed - and he didn't see the problem either.

OK! First build it's broken in is Mozilla/5.0 (Windows NT 6.0; rv:2.0b9pre) Gecko/20101221 Firefox/4.0b9pre The delay while someone else's message sends starts earlier. Sometime after Dec 1 before Dec 12. I'm so not finding the window for that tonight, though! Let me know if it's relevant and I can dig in again. Will also confirm my regression range on XP tomorrow if needed.

Oh and I forgot to say that having the two extensions installed doesn't cause the bug before the regression range. During the regression range the two extensions aren't necessary and after the regression range the two extensions are required to trigger the bug.

(In reply to comment #25) > The bug doesn't entirely happen in Beta 8, but there is some behaviour going > on. I can't type while the other person's message is sending/drawing, but when > they're done I can type again. Branch has the same behaviour, though it feels > not quite so laggy. Please file another bug on that. This might be an entirely different issue.

(In reply to comment #29) > Oh and I forgot to say that having the two extensions installed doesn't cause > the bug before the regression range. During the regression range the two > extensions aren't necessary and after the regression range the two extensions > are required to trigger the bug. By "after the regression range", you mean builds starting with the 20110116 build as you mentioned in comment 27?

Regression range according to comment 28: <http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fc50c521bf48&tochange=fb629ae54510>. Nothing in this regression range looks suspicious. There is definitely no editor/selection/caret related changes here. I will need to ask for help either from Lucy or the QA folks to bisect this range tomorrow.

I've triggered the first bisection build now, it should be ready by tomorrow morning. The range seems to be bisectable at around 5 tests.

Yes, the bug triggered in nightlies in clean profiles from Dec 21 to Jan 15 inclusive. On Jan 16 it got better, but I could still (and can still) make the bug happen with Flashblock AND Test Pilot enabled - haven't tested if any other combinations trigger the bug.

Juan asked me to see if I could repro this, so I tried in the QA lab on Win 7 and Win XP and did have any luck. I tried using B9 on Win 7 and with the B10 candidate on Win XP.

Marcia - please try B9 on XP. With B10 did you also install Test Pilot and Flashblock?

(In reply to comment #35) > Juan asked me to see if I could repro this, so I tried in the QA lab on Win 7 > and Win XP and did have any luck. I tried using B9 on Win 7 and with the B10 > candidate on Win XP. Can you please test on Vista? This should be the first broken build <http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/12/2010-12-21-03-mozilla-central/>, and this should be the last good build <http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/12/2010-12-20-03-mozilla-central/>.

(In reply to comment #36) > Marcia - please try B9 on XP. With B10 did you also install Test Pilot and > Flashblock? Which versions of those add-ons do you have installed?

Flashblock 1.5.14.2 and Test Pilot 1.0.3 (I downloaded them fresh yesterday for testing) My point being it gets better on Jan 16 so B10 won't show this bug on its own.

Anyone who can see this bug, does turning of hardware acceleration help here? Also what happens when you disable Flashblock in it's preferences? Does the behavior persist?

I bet facebook uses a flashsocket for push messages, which flashblock would kill...I'll confirm in a sec.

Can't seem to figure out if that's the case, but it is plausible at least.

Yes I had the latest versions of both Test Pilot and Flashbook installed when testing Beta 10. Will try some other suggested scenarios in the comments. (In reply to comment #36) > Marcia - please try B9 on XP. With B10 did you also install Test Pilot and > Flashblock?

Bisection resulted in <http://hg.mozilla.org/mozilla-central/rev/1ff07ed94d79> from bug 618487. I'm going to create a special build for Lucy from beta10 with only that changeset backed out to see if the same problem happens again. If not, we've found the culprit. Steven, Josh, it would be great if you guys could take a look in the mean time too.

Lucy, can you please paste the contents of about:support on the profile on which you can reproduce this on beta10?

I have a clue! Ok so, bear with me I'll try and make sense. Using b10 Customize the toolbar -> add the flashblock button When Firefox starts with the button set to flash disabled (red x) the bug triggers. Click the button to allow flash (green circle) -> restart Firefox -> bug doesn't happen I've been testing with tabs restoring, because that wasn't making a difference in terms of the regression window. I'll redo my tests without saving any data.

On a new start with no tabs saved one message worked, then I broke. Also confirming that unchecking "Play Sound For New Messages" stops the problem from happening. Also on the new start I noticed only one sound worked, then I stopped getting the chimes. Here's my about:support as requested (note I've been confirming all my findings on another machine running xp) Application Basics Name Firefox Version 4.0b10 User Agent Mozilla/5.0 (Windows NT 6.0; rv:2.0b10) Gecko/20100101 Firefox/4.0b10 Profile Directory Open Containing Folder Enabled Plugins about:plugins Build Configuration about:buildconfig Extensions Name Version Enabled ID Microsoft .NET Framework Assistant 0.0.0 false {20a82645-c095-46ed-80e3-08825760534b} Flashblock 1.5.14.2 true {3d7eb24f-2740-49df-8937-200b1cc08f8a} Feedback 1.0.4 true testpilot@labs.mozilla.com Modified Preferences Name Value browser.places.smartBookmarksVersion 2 browser.startup.homepage_override.buildID 20110121161358 browser.startup.homepage_override.mstone rv:2.0b10 extensions.lastAppVersion 4.0b10 network.cookie.prefsMigrated true places.history.expiration.transient_current_max_pages 64088 privacy.sanitize.migrateFx3Prefs true Graphics Adapter Description Mobile Intel(R) 945GM/GU Express Chipset Family Vendor ID 8086 Device ID 27a2 Adapter RAM Unknown Adapter Drivers igdumd32 Driver Version 7.14.10.1244 Driver Date 3-30-2007 Direct2D Enabled false DirectWrite Enabled false (0.0.0.0) WebGL Renderer (WebGL unavailable) GPU Accelerated Windows 0/1

Actually, on the XP machine the sounds were coming through but they were late, otherwise all findings are the same.

(In reply to comment #44) > Bisection resulted in <http://hg.mozilla.org/mozilla-central/rev/1ff07ed94d79> > from bug 618487. > > I'm going to create a special build for Lucy from beta10 with only that > changeset backed out to see if the same problem happens again. If not, we've > found the culprit. The build in question worked fine for Lucy, so I can confirm that this is a regression from bug 618487.

(In reply to comment #46) Does Facebook Chat use Flash? > Customize the toolbar -> add the flashblock button > > When Firefox starts with the button set to flash disabled (red x) > the bug triggers. > > Click the button to allow flash (green circle) -> restart Firefox -> > bug doesn't happen Does Flashblock block Facebook Chat? (In reply to comment #44) Ehsan, please tell me how, precisely and in detail, you're able to reproduce this bug.

Plugins that are present on both machines I was reproducing this on: Shockwave Flash File: NPSWF32.dll Version: 10.1.102.64 Shockwave Flash 10.1 r102 iTunes Application Detector File: npitunes.dll Version: 1.0.1.1 iTunes Detector Plug-in Silverlight Plug-In File: npctrl.1.0.30401.0.dll Version: 4.0.50917.0 (On Vista) Version: 4.0.51204.0 (On XP) Windows Presentation Foundation File: NPWPF.dll Version: 3.5.30729.1 Windows Presentation Foundation (WPF) plug-in for Mozilla browsers Adobe Acrobat File: nppdf32.dll Version: 9.4.1.222 Adobe PDF Plug-In For Firefox and Netscape "9.4.1" (On Vista) Version: 9.0.0.332 (On XP eek, need to update that) QuickTime Plug-in 7.6.9 File: npqtplugin.dll Version: 7.6.9.0 (Vista) Version: 7.6.8.0 (XP)

(In reply to comment #50) > (In reply to comment #46) > > Does Facebook Chat use Flash? > > > Customize the toolbar -> add the flashblock button > > > > When Firefox starts with the button set to flash disabled (red x) > > the bug triggers. > > > > Click the button to allow flash (green circle) -> restart Firefox -> > > bug doesn't happen > > Does Flashblock block Facebook Chat? > > (In reply to comment #44) > > Ehsan, please tell me how, precisely and in detail, you're able to > reproduce this bug. Ehsan can't reproduce it. How to reproduce it depends on which build we're talking about. Using B10 install flashblock make sure it's set to block flash by default In facebook make sure in chat options "Play sound..." is checked Have someone send you a chat message. See how you cannot type! If you have any more questions it might be easier to ping me on IRC - Lucy - and then post results to the bug.

(In reply to comment #50) > (In reply to comment #46) > > Does Facebook Chat use Flash? Yes. > > Customize the toolbar -> add the flashblock button > > > > When Firefox starts with the button set to flash disabled (red x) > > the bug triggers. > > > > Click the button to allow flash (green circle) -> restart Firefox -> > > bug doesn't happen > > Does Flashblock block Facebook Chat? Yes. > (In reply to comment #44) > > Ehsan, please tell me how, precisely and in detail, you're able to > reproduce this bug. I haven't been able to, unfortunately. But Lucy sees to be able to reproduce this very reliably, and she was the one helping me to bisect this on IRC...

(In reply to comment #53) > (In reply to comment #50) > > (In reply to comment #46) > > > > Does Flashblock block Facebook Chat? > > Yes. > That's misleading. With Flashblock enabled, in a build that has been suffering the problem, unchecking the box to "play sounds..." stops the bug from happening. So very specifically I can chat with Flashblock enabled, with sounds on I have to click away and back to continue typing, but messages are all received and are able to be sent.

(In reply to comment #54) > (In reply to comment #53) > > (In reply to comment #50) > > > (In reply to comment #46) > > > > > > > Does Flashblock block Facebook Chat? > > > > Yes. > > > > That's misleading. With Flashblock enabled, in a build that has been suffering > the problem, unchecking the box to "play sounds..." stops the bug from > happening. > > So very specifically I can chat with Flashblock enabled, with sounds on I have > to click away and back to continue typing, but messages are all received and > are able to be sent. As far as I know, Facebook uses Flash to play the sounds in the chat...

Right, I just wanted to be clear. Blocking the sounds isn't the same thing as blocking the whole chat and this bug is confusing already. ;)

It seems that facebook chat is working for me. I had the problem in Beta 9. Then today i found out there was an update for beta 10. i downloaded the update and the problem seems fixed to me. Not sure if anyone is having the problem in beta 10 because im not.

I was looking at the patch we bisected to, and then I looked at the patches from Jan 15 - 16, and saw the fixes for bug 601064 had landed at that time, this seems to me this is more of the "invisible plugins" mess, in my very amateur opinion! Flashblock still breaks the google listen buttons, you have to enable flash then refresh the page. Could this be the same issue, but in facebook's case the bisected patch makes the chat fail when the sound doesn't go? Let me know here or IRC if I can help out more.

(In reply to comment #57) > It seems that facebook chat is working for me. I had the problem in Beta 9. > Then today i found out there was an update for beta 10. i downloaded the update > and the problem seems fixed to me. > > Not sure if anyone is having the problem in beta 10 because im not. It's broken in B10 for me with Flashblock installed and enabled, if you want to give that a shot.

Do we have contacts among the Flashblock developers? It'd be useful to CC one of them here. I wonder if they're aware that Flashblock doesn't (or at least didn't) block "invisible" Flash plugins?

Apparently Chrome has (or had) a similar problem (there's a Flashblock extension for Chrome): http://www.google.com/support/forum/p/Chrome/thread?tid=6b12d6daff87e732&hl=en Lucy (or someone else who uses Facebook Chat), please check to see if Chrome still has this problem.

(In reply to comment #60) > Do we have contacts among the Flashblock developers? It'd be useful > to CC one of them here. > > I wonder if they're aware that Flashblock doesn't (or at least didn't) > block "invisible" Flash plugins? I don't think this is the issue? on branch, with Flashblock enabled Google translate works fine. Now it blocks it, I assume because of all the extra checks for calls and paints that have been added in.

> I don't think this is the issue? We can't know whether or not this is an important issue until the Flashblock developers talk to us. I'm not trying to get out of fixing this bug (or of working around someone else's bug). I'm trying to understand the larger picture. And since we appear to have a bad interaction between three different "apps" (FF4, Flash and Flashblock), the larger picture is very important to have. By the way, please do test with Chrome and let us know your results. The answer to this question is another important piece of the puzzle (and of the larger picture).

> on branch, with Flashblock enabled Google translate works fine. Now > it blocks it, This is a seperate bug ... though possibly (probably?) a related one. Please open a new bug on it and CC me. I'd very much like to have a related bug to work on that doesn't use Facebook Chat (since I don't have a Facebook account and very much don't want to have one).

With flashblock by josorek chrome downloads the sound before playing it, like people are saying in that link (there's another flashblock that didn't block the sound). With flashblock by josorek installed the listen buttons on google translate are also broken.

(In reply to comment #63) > I'm not trying to get out of fixing this bug (or of working around > someone else's bug). I'm trying to understand the larger picture. > And since we appear to have a bad interaction between three different > "apps" (FF4, Flash and Flashblock), the larger picture is very > important to have. > I'm not implying anything like that! But either way it's a confirmed regression in Firefox, so I'm not sure where you're going. It would be very nice on my end to do a bunch of this triaging over IRC. It makes noises at me, rather than having to check my email ;)

(Following up comment #64) (From comment #58) > Flashblock still breaks the google listen buttons Is this the "Google translate" problem? I understand the special build Ehsan gave you (see comment #44) fixes this bug (the Facebook Chat problem). Does it also fix the "Google translate" problem? The reason I ask is (as I mentioned above) I'd really prefer to have STR for this bug that don't involve using Facebook Chat. If Ehsan's special build fixes both problems, there's a good chance they're related (or even dups). If Ehsan's special bug doesn't fix the "Google translate" problem, then it and the Facebook Chat problem may be unrelated.

Ok so what is happening to facebook is that when the sound is blocked facebook freaks out somehow and loses focus, I guess it's waiting for the sound before it moves on. The build ehsan gave me does not block sounds on facebook, but the listen buttons on google translate are still blocked. It seems like the patch ehsan's build didn't have allows flashblock to see the invisible plugin. Google's must be done slightly differently as flashblock can see the listen buttons even without it. Knowing what facebook is doing would make this a lot easier. It does seem like a bug on their end. I'm not sure why Chrome is downloading the mp3. Is that what they're supposed to do, or did they build a workaround? As in, should Firefox be downloading the mp3, too?

> The build ehsan gave me does not block sounds on facebook, but the > listen buttons on google translate are still blocked. Thanks for the info. This tells me the Facebook Chat and Google translate problems are (probably) unrelated. But to confirm this I'd like to ask another question: Are the Google translate buttons blocked using FF 3.6.13?

> Are the Google translate buttons blocked using FF 3.6.13? Oops. I think you answered this in comment #62. The answer you gave there was "NO".

Any Flash gurus here? Anybody know of freely accessible examples of "invisible" Flash plugins (or how to write one)? Are there special tricks you need to play to load them "invisibly"?

Argh ok, sound is NOT blocked in b10, it's laggy. But typing does break. Typing didn't break in chrome. Also remember typing breaks in *any* text field. Oh nice, typing broke in THIS one but I was testing in another browser.

oh good, I spoke too soon. I still had a facebook tab open in this browser, so I can now confirm bug still exists in latest nightly ;)

(In reply to comment #67) > The reason I ask is (as I mentioned above) I'd really prefer to have > STR for this bug that don't involve using Facebook Chat. Could you get the login info for Curly from marketing?

>> The reason I ask is (as I mentioned above) I'd really prefer to >> have STR for this bug that don't involve using Facebook Chat. > > Could you get the login info for Curly from marketing? Thanks for the suggestion. I should probably do this via email (not here in world-readable comments). To whom (which email address) should I send my request?

> To whom (which email address) should I send my request? Never mind. I emailed Chris Beard.

When flashblock is blocking the sound, it's falling back using Quicktime. Disabling Quicktime solves the bug without restart. Reenabling Quicktime without restart makes it come back.

Ok tested without flash installed at all, bug still happens. New and improved steps to reproduce: 1. Uninstall or block flash 2. Install/enable Quicktime 3. Sign in to facebook 4. Enable chat, and make sure "play sounds for new messages" is checked 5. Place focus in any text field - bugzilla comment, facebook chat 6. Receive facebook chat message 7. Try to type. AHA you can't! If people who weren't seeing this could test again with these steps, I bet we can make it happen on win7, too.

I'm CCing Lorenzo Colliti here, who is the primary developer of Flashblock according to <https://addons.mozilla.org/en-US/firefox/addon/flashblock/developers>. I don't know if he reads the bugmail for this address, so I'm also CCing Blizzard to see if he knows of other ways to reach out to Flashblock developers.

(In reply to comment #78) > 1. Uninstall or block flash You mean disable Flash or enable Flashblock? Anyway, thanks for the improved STR. Now we've got a four-way bad interaction :-)

(In reply to comment #80) > (In reply to comment #78) > > > 1. Uninstall or block flash > > You mean disable Flash or enable Flashblock? > > Anyway, thanks for the improved STR. Now we've got a four-way bad interaction > :-) well, you can uninstall it or disable it. There are also other extensions that will block flash. And no, it's not a four-way interaction. It's firefox and quicktime. *possibly* facebook is needed. Flashblock is not.

Got confirmation that this bug *Does* happen on Win7 given the new STR! People just don't put itunes on their work machines so no one in QA could repro.

> I'm CCing Lorenzo Colliti here, who is the primary developer of Flashblock > according to > <https://addons.mozilla.org/en-US/firefox/addon/flashblock/developers>. I > don't know if he reads the bugmail for this address, so I'm also CCing Blizzard > to see if he knows of other ways to reach out to Flashblock developers. Hi sorry for the delay in noticing this. Now that I'm on the SeaMonkey Council, I'm getting burried in bugspam. Lorenzo is listed first on AMO because AMO lists authors alphabetically. But I've been the Project Owner for the last few years. The regular developers in Core::Plugins and Core::Plugins::Adobe::Flash know to CC me on anything related to Flashblock (usually). > Got confirmation that this bug *Does* happen on Win7 given the new STR! People > just don't put itunes on their work machines so no one in QA could repro. I think installing QuicktimeAlternative should install the core QT plugin and the necessary codecs without the overhead of iTunes and other bloatware.

I found another site that uses Quicktime for audio and breaks focus, but it's a completely different regression window. Going to have to use Facebook to triage this one. Will find a regression window on the other one and file, link back here.

(In reply to comment #84) > I found another site that uses Quicktime for audio and breaks focus, but it's a > completely different regression window. Going to have to use Facebook to triage > this one. Will find a regression window on the other one and file, link back > here. Please file a different bug for this. This bug is only about Facebook chat not working, and that's the reason that it's a hardblocker. We shouldn't start investigating other problems here.

Yes, I already said I'd file a new bug. I said I'd *link* it in here. You know, so people could find it. I really don't know why you couldn't tell me that on IRC if you were worried about cluttering the bug. I'm the one doing all the heavy lifting (though thank you for making the bisecting builds for me to test), I know *exactly* what this bug is about. I understand you're just trying to be clear, but I'm getting tired of being spoken to like I don't know what I'm doing. If this bug is only about facebook chat then maybe it should be assigned to someone who's willing to use facebook?

> If this bug is only about facebook chat then maybe it should be > assigned to someone who's willing to use facebook? I'm working on getting access to a testing account (I've emailed a couple different Mozilla people). No response yet. By the way, I've got a question for you: In comment #82 you mentioned iTunes, without saying anything about what role it plays in reproducing this bug. Please provide more detail.

Quicktime comes with iTunes. If you have iTunes you have Quicktime. These days if you don't have iTunes you probably don't have Quicktime on Windows, it's not used much anywhere else anymore. People use flash instead, which is why it was so hard for me to find another site to test with. I ended up scraping embed bugs in bugzilla to find a link that still worked. So if you have a Windows user, who has iTunes, who is blocking flash somehow/doesn't have it installed, they will see this bug when they chat on Facebook.

(In reply to comment #88) Thanks! I was beginning to dread that I'd need an iTunes account, too :-( I actually have QuickTime without iTunes on Windows. But (if I remember right) I had to uncheck the iTunes box when I did the installation.

I've now got a Facebook account and will start testing with it (probably tomorrow). Thanks to those who helped me!

Other bug I found is filed at Bug 629593. They may be related, as I think they both deal with Quicktime and OOPP. I can't reproduce this (facebook) bug with OOPP disabled. Anyway, as Ehsan correctly states, anyone interested in that bug, please join me there!

With Ehsan's help, and using my new Mozilla Tester Facebook account, I'm able to reproduce this bug on Windows XP with today's Minefield nightly. I tested with Flash disabled (in Add-Ons) and with the latest version (7.6.9) of QuickTime installed. (I didn't install iTunes, but that's probably not relevant.) I didn't disable OOPP (I didn't turn dom.ipc.plugins.enabled off). Here's what happened (in Facebook Chat): 1) I typed a line and pressed Enter. It appeared in the Facebook Chat "window" (above the text entry field) and Ehsan saw it on his side. 2) Ehsan responded. I saw his response, and after about a second heard a beep (presumably from QuickTime). 3) But now I was no longer able to type in the text entry field at the bottom of the Facebook Chat "window". I typed a few words and pressed Enter. But nothing appeared on my side (either in the text entry field or the "window" above it), and Ehsan didn't see my response. Apparently the text entry field had lost focus (though the text entry cursor was still flashing in it). I was able to restore focus by clicking just outside the Facebook Chat "window", then again in the text entry field just below it. I'm going to spend the next few hours writing a debug-logging patch and building it on the tryservers. If any of you get "friended" in Facebook by "Mozilla Tester", that's me :-)

I just tested again with Ehsan, and confirmed that this bug doesn't happen with OOPP off (with dom.ipc.plugins.enabled set to false).

(In reply to comment #93) > Apparently the text entry field had lost focus (though the text > entry cursor was still flashing in it). For what it's worth it's very easy to reproduce blinking cursor without focus: - options - general - when minefield starts - show a blank page - close minefield - start minefield but before window shows up, switch focus to another app (say, desktop). You now have an unfocused minefield window with blinking cursor in its url bar. This is not a regression, it's been this way since I remember. Perhaps this is completely unrelated in which case I apologise for the noise. But perhaps the state is similar to this bug, in which case this is a trivial way to reproduce.

Radek - the bug is already long enough, don't worry about it ;) The blinking cursor isn't really the focus point here, but that's for pointing out that it happens in other cases. What really tells us focus is broken is that we can't type even *though* the cursor is broken. If you follow the Steps To Reproduce, you can break typing every time. For your bug, if you use the keyboard to switch back to the minefield window, and then start typing does typing enter where the cursor is flashing, or do you have to use the mouse to select a field first? If typing doesn't work even with the window selected, and the cursor flashing then you have a bug ;) It sounds like a bug to me either way! File it, and cc me?

(In reply to comment #85) > This bug is only about Facebook chat not > working, and that's the reason that it's a hardblocker. We shouldn't start > investigating other problems here. If the main concern is making Facebook work and not so much fixing a generic plug-in issue, has evangelizing Facebook to use <audio> been tried?

> has evangelizing Facebook to use <audio> been tried? I haven't, and I don't know who'd be an appropriate person to do this. We could make a strong case that the <audio> tag is simpler and better here: Facebook wouldn't have to worry about it being blocked, and so wouldn't have to implement a complex solution where they prefer one plugin but optionally fall back to another. But even if the change was trivial, they'd have to test it, and this would take time. And I suspect that both this bug and bug 629593 are "our fault". So if I can find an easy fix, we should probably take it.

(In reply to comment #99) > We could make a strong case that the <audio> tag is simpler and better > here: Facebook wouldn't have to worry about it being blocked, and so > wouldn't have to implement a complex solution where they prefer one > plugin but optionally fall back to another. > The fallback is generic, they don't specify to use quicktime. It's quicktime that takes over mp3s by default. Can we force some plugins to *not* use OOPP? Quicktime doesn't show these bugs with OOPP disabled.

> The fallback is generic, they don't specify to use quicktime. It's > quicktime that takes over mp3s by default. The <audio> tag would still better here, right? (I'm not saying we should rely on Facebook to use it in the near future -- just that this is a good example of its superiority to plugins.) > Can we force some plugins to *not* use OOPP? Quicktime doesn't show > these bugs with OOPP disabled. That would be overkill just to fix this bug.

Well, *right now* our other option is backing out your other patch. Yes, the best situation is fixing the underlying bug, but that *may* not be realistic in time for Fx4. Just curious if it's an option if we (you) get stuck.

Indeed the call to SetWindow ends up with user32.dll sending a WM_KILLFOCUS message on the browser window. This message is not generated with OOPP disabled. Also, somewhat tangent to the problem, but this message does not come together with a corresponding WM_ACTIVATE (param=deactivate). This is likely the reason why the focus state ends messed up. Though of course the WM_KILLFOCUS shouldn't be happening in the first place

(In reply to comment #103) > Indeed the call to SetWindow ends up with user32.dll sending a > WM_KILLFOCUS message on the browser window. This is the problem I'm concentrating on in my attempt to fix bug 629593 (and this bug). I hope to have something definite to say in the next day or two. In fact the WM_KILLFOCUS message is sent whether or not the browser is doing OOPP. But when doing OOPP there doesn't appear to be any corresponding WM_SETFOCUS message. Both messages appear to be triggered by something the QuickTime plugin does during the first call to its NPP_SetWindow() method. I'm working to find out exactly what.

Ok here's some more info that I got and a theory; hopefully this can be helpful and not going in the wrong path. > In fact the WM_KILLFOCUS message is sent whether or not the browser is doing OOPP. This is true, I hadn't noticed this at first. But the WM_SETFOCUS exists too: it's dispatched to the plugin-container process with OOPP enabled. With that in mind, I set a breakpoint in user32.dll's SetFocus and saw that the quicktime plugin clearly calls directly into that (stack below). theory: So I believe that the QuickTime has the opposite quirk from the one fixed in bug 618487, and it has also been triggered by the difference in timing for the SetWindow calls. This is not a problem with OOPP disabled because the kill/setfocus goes both to the same process and the focus manager deals with that. This was not a problem before bug 618487 because the plugin is hidden so it never received SetWindow. Why this didn't happen before bug 594482 is beyond me, but it does looks like some timing thing. If I change this condition: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#1212 to always use the async call, this bug goes away. But I don't know what are the consequences of doing that. stack: > user32.dll!75d81b99() [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll] QuickTimeWebHelper.qtx!6da2e1e1() QuickTimeWebHelper.qtx!6da13b61() xul.dll!mozilla::plugins::PluginInstanceChild::AnswerNPP_SetWindow(const mozilla::plugins::NPRemoteWindow & aWindow={...}) xul.dll!mozilla::plugins::PPluginInstanceChild::OnCallReceived(const IPC::Message & __msg={...}, IPC::Message * & __reply=0x00000000) ...

Felipe, what do you recommend we do? ;-) I'm a little lost in the details here.

By the way, I've discovered that the QuickTime plugin calls SetFocus() with a NULL hWnd (whether or not we're using OOPP). This appears to be all it does that might effect keyboard focus. I'm trying to stop this from happening by hooking the call to SetFocus(), as we already do with SetWindowLong(). But I haven't yet managed to get the hook to work. Felipe, does this sound like a good strategy?

Another thing: I haven't yet given up trying to find a fix for this bug (actually for bug 629593, which should also fix this bug). But we need to think about what we should do if we *can't* find a reasonable solution (or at least can't find one quickly enough). My suggestion is to get rid of the blocker designation and just relnote this problem. When this bug was made a blocker, it was very poorly understood. Since then the scope has been considerably narrowed, and it seems to have a reasonable workaround -- configure FlashBlock not to block Flash on Facebook pages. (Someone who knows FlashBlock and Facebook better might be able to find a way just to stop FlashBlock from blocking Flash while doing Facebook Chat.)

So, if my understanding is correct about the NPAPI in that hidden plugins shouldn't expect to receive any SetWindow calls, I'd suggest that we revert the change made in bug 618487 and add that as a quirk only for the DivX plugin.

We recently standardized in the NPAPI that hidden plugin instances receive a notification that they are hidden (via NPP_SetWindow) where the window rect is 0,0,0,0. We need to not break that, except perhaps as a quicktime-specific quirk. See bug 583109

The first call to SetWindow() (the one that triggers QuickTime's call to SetFocus()) sends a non-zero window rect.

And by the way, I'm happy with a solution that uses quirks for the DivX plugin and/or the QuickTime plugin.

Do you want to take this bug, Felipe? My Windows builds are very slow, since I run Windows in VMWare and tryserver builds are also very slow.

(In reply to comment #111) > The first call to SetWindow() (the one that triggers QuickTime's call to > SetFocus()) sends a non-zero window rect. Hmm this is very odd, I thought I saw it sending 0,0,0,0. This might be the reason why quicktime calls SetFocus. Also, I'm curious, why does plugins with UseLayers() calls AsyncSetWindow, and the others call SetWindow directly?

Because that's how async layers is implemented. On Windows you really only need to worry about the AsyncSetWindow case, the sync SetWindow call is going away.

> (In reply to comment #111) >> The first call to SetWindow() (the one that triggers QuickTime's >> call to SetFocus()) sends a non-zero window rect. > > Hmm this is very odd, I thought I saw it sending 0,0,0,0. SetFocus() (the Win32 API call) takes a single parameter -- an hWnd (which I believe resolves to an int). By the way, what's really wierd (to me) is that, when QuickTime calls SetFocus(NULL) in non-OOPP mode, this results in both a WM_KILLFOCUS message and a WM_SETFOCUS message. According to Microsoft's docs on SetFocus(), calling it with a NULL hWnd is supposed to prevent the keyboard focus from going anywhere ("if this parameter is NULL, keystrokes are ignored"). > Also, I'm curious, why does plugins with UseLayers() calls > AsyncSetWindow, and the others call SetWindow directly? That I don't know.

> (In reply to comment #111) >> The first call to SetWindow() (the one that triggers QuickTime's >> call to SetFocus()) sends a non-zero window rect. > > Hmm this is very odd, I thought I saw it sending 0,0,0,0. This > might be the reason why quicktime calls SetFocus Oops, sorry -- I misread your comment. By the way, my information about SetWindow's behavior comes from debug logging, not from breaking inside a debugger. That may have made a difference.

(Following up comment #117) I took another look at my logs, and confirmed that I remembered correctly -- even the first call to NPP_SetWindow() has a non-zero window size. The clipRect is indeed set to '0,0,0,0', but I thought the clipRect was ignored on all platforms except the Mac.

That's interesting. I'll take a look now at the plugin geometry to see if I can spot where does that come from.

(Following up comment #118) Oops. The logs I'm talking about are for bug 629593, not this bug. Bug 629593's testcase has a visible QuickTime plugin; this bug's QuickTime plugin is invisible. Sorry. Sigh :-(

(In reply to comment #107) > I'm trying to stop this from happening by hooking the call to > SetFocus(), as we already do with SetWindowLong(). But I haven't yet > managed to get the hook to work. We might have to update the interceptor to work with this call. Check to see if CreateTrampoline fails. If so the instructions we need to move to insert our jmp instruction aren't supported yet. Unfortunately, in some cases you can't hook because there isn't enough space or there are relative addresses at the start of the call. It's sort of hit and miss. http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsWindowsDllInterceptor.h#155 I can help debug if needed.

Patch with the approach discussed today on adding the quirk for DivX only. I believe this is safer than hooking the SetFocus call. I've verified locally that this fixes the facebook chat and do not regress bug 618487. It doesn't fix bug 629593 though (this was somewhat expected given bug 629593 comment 20)

> It doesn't fix bug 629593 though (this was somewhat expected given bug > 629593 comment 20) In fact it's entirely expected, given comment 22. That bug also exists on branches so it's not a recent regression

(In reply to comment #121) Thanks for the suggestion ... and the offer. It's indeed WindowsDllInterceptor::CreateTrampoline() that's failing. The error is "Unknown x86 instruction byte 0xb8". That probably rules out being able to hook SetFocus(), at least for the time being. I'll try to think of other ways to fix bug 629593. And do let me know if you think of something. But now that this bug (bug 626016) has it's own, separate fix, fixing bug 629593 is (I think) much less urgent. I'll post future comments on this subject at bug 629593.

The patch breaks test_visibility.html from bug 583109. I don't understand why as the patch mostly reverts bug 618487 and the test was presumably working before that.

Almost sure that the different behavior in the test is due to the changes made to the test in Bug 601064

The test passes with these changes, which is very odd because it indicates that the plugin doesn't get painted on startup, however it did not regress bug 601064 nor test_painting.html which was added with it

Roc, any idea why test_visibility.html would require these changes with this patch, but still this doesn't break what was fixed in bug 601064? Do you think that this test change is correct?

Comment on attachment 511912 [details] [diff] [review] Test change Adding roc as reviewer, as felipe's commented suggests is appropriate.

These changes don't look good. I think you need to figure out why the test plugin isn't being painted on startup.

So the missing paint is because the new paint-on-startup from bug 601064 really depends on the SetWindow path that I was trying to remove. Roc suggested that what we should do then is add this quirk only for quicktime, so this patch does this. Small upside is that the changes are all in the content process now.

For what it's worth, I've got a patch (and tryserver build) at bug 629593 that should fix this bug. See bug 629593 comment #31.

> For what it's worth, I've got a patch (and tryserver build) at bug > 629593 that should fix this bug. See bug 629593 comment #31. I just did a test of Facebook chat with Ehsan, and had no problems. I tested with my tryserver build from bug 629593 comment #31, with QuickTime installed and Flash disabled. Others please try it, too. I'm only able to test on Windows XP.

WFM with the build from bug 629593

Comment on attachment 512395 [details] [diff] [review] Patch v2 I think I like this patch better.

FIXED!! Teamwork :D

I can reproduce this with http://www.toronto.ca/garbage/single/calendars/friday_2.pdf (and other embedded pdfs) Will this be a separate bug, or does that mean this isn't really fixed? using http://hg.mozilla.org/releases/mozilla-aurora/rev/a5a5c583c381 Only tested on this one so far.

argh sorry, I posted that to the wrong bug *sigh* I'm not reproducing this one, it's the one I found while testing this one.