User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:23.0) Gecko/20130411 Firefox/23.0 Build ID: 20130411030925 Steps to reproduce: Tried to edit a Google Document. Actual results: No matter what I press on the keyboard, nothing happens. I'm able to move the cursor by clicking the mouse but I can't even use the arrow keys to do so. Expected results: It should add whatever text I'm typing into the document. This has been happening in Nightly builds for at least a few days now I think.

By the way, it happens on both Windows and Linux builds, so it isn't isolated to one particular OS, however I'm hesitant to mark the OS as "All" because there's a lot of other things listed there.

I tested and it works fine for Linux builds..maybe it's a problem with the document, can you try with other ones ?

I've noticed the same problems, also starting three or four days ago. I've tried a few different documents (both new and old ones) and found that while I cannot edit documents and presentations, I can edit spreadsheets. User agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20130412 Firefox/23.0

"Me too". Occurs in Firefox "safe mode" as well.

I confirm, works only for spreadsheets

I'll also add that I cannot copy any text from an existing Google Document (Ctrl+C / Ctrl+V somewhere else won't paste anything)

I also have this problem on Windows and Linux: Good: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20130409 Firefox/23.0 ID:20130409030855 CSet: b1fb34b07c17 Bad: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20130410 Firefox/23.0 ID:20130410031044 CSet: 9db46ddfb517

Narrowed it down to bug 765780 by building locally: good: http://hg.mozilla.org/integration/mozilla-inbound/rev/ad371c559524 bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/fbc229932c90

I'll look into it first thing on Monday, but at first glance Google docs depends on script being disabled somewhere... which WebKit doesn't do, of course. So I suspect they're doing some sort of browser-sniffing. :(

So I just tried something very simple: take a build from _before_ bug 765780 and just change CanExecuteScripts to always return true. The result shows this same problem. I'm going to mail the Google folks and see what's going on here, because this is sure looking like a bug on their end...

This wouldn't be the first time I've had issues with browser sniffing and Google while using Nightly builds, and I doubt it will be the last. Oh well. Since this obviously isn't restricted to 64-bit hardware now, I've set that to All.

Sounds like this might end up being evangelism/google bug, and possibly only affect nightly - so not moving up to aurora with 23 when we merge but I'll track in order to make sure, once we're on Aurora, that this isn't reproducing anymore.

I'm looking into this from the Google Docs-side. We don't run scripts in the designMode/contentEditable iframe AFAIK. It seems like I am seeing some behavior differences vs stable FF (and Aurora): 1) Previously for Gecko, we would assume the designMode iframe was available and can be focused immediately after being added to the DOM. That no longer seems to be the case and it seems like we should be waiting for the load event from the iframe. Let me know if this is intended. A reproduced test case is attached that demonstrates not waiting for the load event. In FF stable the focus is in the designMode iframe and typing will add content. In FF23, that is no longer the case. Additionally, at least on Mac OS X, it does not even appear I can click into that iframe. I can never get the cursor to show. 2) Even with that, I am seeing some focus issues when using designMode. However, I can't get an isolated test case to reproduce these. Switching to contentEditable removes the issue so I will just do that. I will still try to reduce this. 3) I am also seeing another focus issue where we can no longer just focus the contentWindow of the iframe - instead we must focus the body of the iframe. Again, I can't get an isolated test case and the new behavior is still reasonable. Because of incorrect focus, the input is not being recognized in Docs. It would be great if #1 can be investigated, and if any of the other issues are expected (I don't have test cases for those, so will those are a bit tougher). I do have a change for Docs where it will work at least as far back as FF20. I need to do further testing.

Wworks on FF22 and below, does not work on FF23.

works on FF at least as far back as FF20 (including FF23)

works on FF at least as far back as FF20 (including FF23) (last one had an incorrect setupFrame) call

Steven, thank you! I can definitely reproduce your issue #1 and can confirm that it happens due to the "always allow script" change. Apparently something in the logic that was checking for designMode so as to disallow script had some sort of side effect on the loading process... I'll hunt it down. Let's not worry about #2 and #3 for now, though the fact that behavior changed there is very odd.... I'm hoping that they're somehow related to #1 and fixing it will help.

OK, so I was wrong about the "check for script enabled" logic having side-effects. ;) Looking at the attached testcase more closely, there _is_ a script that tries to run in that designMode iframe. It's right here: iframe.src = 'javascript:""'; What this does is kicks off an async attempt to run the empty script, which of course does nothing if we disallow script in designMode iframes, because script is disabled inside the iframe. Per the spec at http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#javascript-protocol this is treated the same as if the script returned undefined. But on mozilla-central, we do allow the script to run. The script not only runs, it returns a value that's a string. And per that same spec since the return value is not undefined the return value is treated as HTML and creates a _new_ document (in this case one parsed from an empty string). Of course the new document is not in design mode, since that was set on the old document. Note that WebKit's handling of javascript: urls is all kinds of broken and doesn't follow this spec at all, so it's entirely possible that javascript:"" in WebKit does not lead to a new document in this situation. That would explain why things are not broken in WebKit even though it allows scripts in designMode documents. If I change the testcase to do: iframe.src = 'javascript:undefined'; or iframe.src = 'javascript:(void 0)'; so that it actually returns undefined, then focus and editing works. Steven, making one of those two changes on your end should give you the behavior you're actually looking for: that of not creating a new document for the javascript: load, and fix issue #1. If you do that, are issues #2 and #3 still present?

Thanks for the detailed info! That indeed fixes the issue alone on FF, and the focus issues I were seeing are no longer reproducible. NOTE: Yea, cross-browser support for that exact spec seems varied. IE (IE9 specifically) appears to not load with either iframe suggestion. Chrome/Safari will work, but then does not follow the spec exactly as it will reload the iframe when setting the source on an existing iframe (at least as far I can tell from the spec). After the change to using 'javascript:undefined' in Docs, just typing a sentence in Docs crashes FF nightly (browser crash, closes all of FF), at least on Mac OS X. This does not happen on FF stable. Not sure how you want to proceed to investigate that. I doubt it is related to the particulars of this bug. I will make the change in Docs to point at 'javascript:undefined'. Might be easier to investigate the crash after you can use a Docs build with that fix.

Sounds good. Crashes should be pretty easy to pin down on our end, and they're clearly something that's a bug in our code, not yours. Thanks for looking into this stuff!

Steven, do you know what the ETA is on rolling out the change to 'javascript:undefined'?

It should rollout ~early next week. Roughly Monday/Tuesday timeframe. May 6th-7th

(Note that I landed a patch <https://hg.mozilla.org/integration/mozilla-inbound/rev/cace8e8e8556> with this bug number by mistake -- it's really a patch for bug 867324 which is completely irrelevant here.)

I was able to edit a Google Doc today after I restarted with today's nightly. Good job! It did NOT crash on me, as per 869027.

Can confirm working here on 23.0a1 (2013-05-02) - from not working, full reload of tab with doc in it (FF not restarted) returned edit functionality.

Confirm working on 20130506 nightly.

Looks like this is fixed now.

Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20100101 Firefox/23.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 Verified as fixed on Firefox 23 Beta 5 (build ID:20130711122148)