Last Comment Bug 549262 - Can not scroll down on a Page using contenteditable="true" by pressing "Space" Key
: Can not scroll down on a Page using contenteditable="true" by pressing "Space...
Status: VERIFIED FIXED
: testcase
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: All All
: -- normal with 3 votes (vote)
: mozilla7
Assigned To: :Ehsan Akhgari (away Aug 1-5)
:
Mentors:
http://tieba.baidu.com/f?kw=c%2B%2B
Depends on: 754169 768838
Blocks: contenteditable
  Show dependency treegraph
 
Reported: 2010-02-28 19:05 PST by Brian
Modified: 2012-06-27 04:46 PDT (History)
13 users (show)
ehsan: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (275 bytes, text/html)
2010-07-22 06:46 PDT, Arjan
no flags Details
Patch (v1) (5.29 KB, patch)
2010-09-06 14:00 PDT, :Ehsan Akhgari (away Aug 1-5)
roc: review+
Details | Diff | Splinter Review

Description Brian 2010-02-28 19:05:46 PST
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) 2010-03-01 04:05:35 PST
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 2010-03-05 07:56:41 PST
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 2010-04-29 18:01:41 PDT
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 2010-07-22 06:46:59 PDT
Created attachment 459420 [details]
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 XtC4UaLL [:xtc4uall] 2010-09-06 03:25:11 PDT
(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 :Ehsan Akhgari (away Aug 1-5) 2010-09-06 14:00:41 PDT
Created attachment 472478 [details] [diff] [review]
Patch (v1)
Comment 7 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-09-06 14:15:52 PDT
Shouldn't the editor be ignoring Space when the editable content doesn't have focus?
Comment 8 :Ehsan Akhgari (away Aug 1-5) 2010-09-07 09:31:26 PDT
(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 :Ehsan Akhgari (away Aug 1-5) 2010-09-09 12:24:20 PDT
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] 2010-09-09 12:59:54 PDT
Could the xbl use bubble phase and system event group?
Comment 11 :Ehsan Akhgari (away Aug 1-5) 2010-09-09 15:51:58 PDT
(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 [:bz] 2010-09-09 19:14:08 PDT
> and I don't know why.

What's the blame for that line (CVS blame, probably)?
Comment 13 :Ehsan Akhgari (away Aug 1-5) 2010-09-21 15:03:29 PDT
(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 :Ehsan Akhgari (away Aug 1-5) 2010-09-21 15:03:50 PDT
(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 [:bz] 2010-09-21 21:37:35 PDT
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] 2010-09-22 02:38:24 PDT
(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) (Exited; email my personal email if necessary) 2010-10-14 02:24:56 PDT
Comment on attachment 472478 [details] [diff] [review]
Patch (v1)

See comments
Comment 18 :Ehsan Akhgari (away Aug 1-5) 2011-06-29 12:48:11 PDT
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) (Exited; email my personal email if necessary) 2011-06-29 17:11:52 PDT
Comment on attachment 472478 [details] [diff] [review]
Patch (v1)

Review of attachment 472478 [details] [diff] [review]:
-----------------------------------------------------------------
Comment 20 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-06-30 06:13:07 PDT
http://hg.mozilla.org/mozilla-central/rev/5b365b5e9213
Comment 21 Jesse Ruderman 2011-07-02 18:54:52 PDT
Arrow keys are still busted. Filed bug 669026.
Comment 22 Trif Andrei-Alin[:AlinT] 2011-08-23 06:41:11 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.