User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; MS-RTC LM 8) Build Identifier: Firefox 3.6 When 'space' key is pressed, the page just scrolls down to the bottom of the browser screen. Reproducible: Always Steps to Reproduce: 1. Navigate to http://tieba.baidu.com/f?kw=c%2B%2B by firefox. 2. Press 'space' key on keyboard. Actual Results: The page scrolls down to the bottom of the screen Expected Results: The page should scroll down for only one page This defect also occurs if press '↑' and '↓' keys on keyboard.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2pre) Gecko/20100225 Namoroka/3.6.2pre Space does nothing on this page. It once worked correctly with Firefox 2.0.

Sorry, my fault, it does nothing on this page now. But I think 'does nothing' is unreasonable, since Space can work fine on other web pages and Space key also can be used to scroll down page correctly if this page be opened in IE browser.

Similar problem. Keys such as PageUp and PageDown are malfunctioning as well. But those keys do function in other browsers such as Chrome. This bug can be reproduced with most pages on tieba.baidu.com, such as http://tieba.baidu.com/firefox, http://tieba.baidu.com/thunderbird, just to name a few. Reference: http://groups.google.com/group/mozilla.support.firefox/browse_thread/thread/c5d516221328f14a

See attached testcase. It is because of the contentedible="true". If you remove it from the original page, the space/pageup/pagedown start working again.

(In reply to comment #1) > Space does nothing on this page. It once worked correctly with Firefox 2.0. I guess this is because Fx2 ignores contenteditable="true" since it has been introduced in Fx3 (Bug 237964).

Shouldn't the editor be ignoring Space when the editable content doesn't have focus?

(In reply to comment #7) > Shouldn't the editor be ignoring Space when the editable content doesn't have > focus? It does. The problem here is not that the editor is eating the event, it's that the event handler is not bound to the document at all.

So, this breaks pressing space in designMode documents, because the XBL is bound to the :root element, and it's called before nsEditorEventListener::KeyPress, which bails out if the preventDefault flag on the event is set. I tried adding preventdefault="false" on the <handler> elements, but it didn't work. It seems that we're calling preventDefault unconditionally here: <http://mxr.mozilla.org/mozilla-central/source/content/xbl/src/nsXBLPrototypeHandler.cpp#493>, and I don't know why. CCing some people who might know that...

Could the xbl use bubble phase and system event group?

(In reply to comment #10) > Could the xbl use bubble phase and system event group? Possibly, but I don't really know how to test it...

> and I don't know why. What's the blame for that line (CVS blame, probably)?

(In reply to comment #12) > > and I don't know why. > > What's the blame for that line (CVS blame, probably)? The first time that this code has appeared seems to be <http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/content/xbl/src&command=DIFF_FRAMESET&file=nsXBLPrototypeHandler.cpp&rev2=1.6&rev1=1.5>, which is marked to map to bug 48758. But there's absolutely no useful information in that bug.

(In reply to comment #11) > (In reply to comment #10) > > Could the xbl use bubble phase and system event group? > > Possibly, but I don't really know how to test it... Smaug, can you please let me know how I can try that? Thanks!

Hmm. So in this case the point is that the xbl handler sometimes doesn't want to perform its "default action", right?

(In reply to comment #14) > (In reply to comment #11) > > (In reply to comment #10) > > > Could the xbl use bubble phase and system event group? > > > > Possibly, but I don't really know how to test it... > > Smaug, can you please let me know how I can try that? Thanks! in the <handler> element set phase to bubble and group to system? You could also play with nsXBLService::AttachGlobalKeyHandler

Comment on attachment 472478 [details] [diff] [review] Patch (v1) See comments

Comment on attachment 472478 [details] [diff] [review] Patch (v1) Actually, I think this patch is correct. The bug is not caused by the editor somehow masking the command handler; it's caused by the fact that the platformHTMLBindings.xml#browser binding is not applied to editable documents at all: <http://mxr.mozilla.org/mozilla-central/source/content/xbl/src/nsXBLWindowKeyHandler.cpp#275>. So, I still think this is the correct fix to the bug...

Comment on attachment 472478 [details] [diff] [review] Patch (v1) Review of attachment 472478 [details] [diff] [review]: -----------------------------------------------------------------

Arrow keys are still busted. Filed bug 669026.

Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0 Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0 Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20100101 Firefox/7.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20100101 Firefox/7.0 I've runned the testcase on all the platforms from above and the issue is no longer reproducible. Setting resolution to VERIFIED FIXED.