549262 - Can not scroll down on a Page using contenteditable="true" by pressing "Space" Key

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Brian]

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.

Comment 1

[Ria Klaassen (not reading all bugmail)]

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.

Comment 2

[Brian]

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.

Comment 3

[Zane Tu]

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

Comment 4

[Arjan]

Attachment: Testcase

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.

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

(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).

Comment 6

[(no longer active)]

Attachment: Patch (v1)

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 8

[(no longer active)]

(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.

Comment 9

[(no longer active)]

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...

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Could the xbl use bubble phase and system event group?

Comment 11

[(no longer active)]

(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...

Comment 12

[Boris Zbarsky [:bzbarsky]]

> and I don't know why.

What's the blame for that line (CVS blame, probably)?

Comment 13

[(no longer active)]

(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.

Comment 14

[(no longer active)]

(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!

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

(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 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

See comments

Comment 18

[(no longer active)]

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 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Review of attachment 472478 [details] [diff] [review]:
-----------------------------------------------------------------

Comment 20

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

http://hg.mozilla.org/mozilla-central/rev/5b365b5e9213

Comment 21

[Jesse Ruderman]

Arrow keys are still busted. Filed bug 669026.

Comment 22

[Trif Andrei-Alin[:AlinT]]

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.