296764 - arrow keys do not move cursor in input fields with javascript disabled

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Michael]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050605 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050605 Firefox/1.0+



Reproducible: Always

Steps to Reproduce:
1. Disable Javascript under Tools->Options->Content
2. Type something in the location bar and try to use the arrow keys to move the
cursor.
Actual Results:  
The cursor stays where it is.

Expected Results:  
The cursor should move.

This first appeared with the 20050603 trunk builds.

Comment 1

[Oliver Saier]

I can reproduce (with 3. Restart Firefox)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050604
Firefox/1.0+ ID:2005060409

Comment 2

[Caleb]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050605
Firefox/1.0+ ID:2005060522

Confirmed (with a restart after step 1).

-> New

Comment 3

[Martijn Wargers (dead)]

Works with 2005-06-02 build, reporter says it fails with 2005-06-03 build.
Could this be a regression from fixing bug 292464?

Comment 4

[[e-mail]]

Discovered independently using a GTK1 Suite build.

Comment 5

[Peter van der Woude [:Peter6]]

in the 2005-06-02 16:04 pdt build (releasetime) in works
in the 2005-06-02 22:46 pdt build (releasetime) in fails

rought timeframe
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-02+15%3A30%3A00&maxdate=2005-06-02+22%3A20%3A00&cvsroot=%2Fcvsroot

Comment 6

[Wevah (Nate Weaver)]

I see this in Camino, too. Option-delete (for delete-word) doesn't work with
JavaScript disabled, either.

(Also, Hardware -> All)

Comment 7

[Boris Zbarsky [:bzbarsky]]

There's a nontrivial chance that this is caused by bug 292591, actually... 
Could someone please check on that?  Things should work as long as the XBL
that's attached to the page has the system principal, but I wouldn't be that
suprised if it doesn't in this case...

Comment 8

[Daniel Veditz [:dveditz]]

Confirming in 1.0.4+ (where bug 292591 also landed). If you turn off javascript
it doesn't seem to affect the current window, but if you open any new windows or
restart you see the bug.

Comment 9

[Chase Phillips]

doron, aaron: do you understand how this bug could be happening? (asking on
behalf of 1.0.5 meeting)

Comment 10

[Doron Rosenberg (IBM)]

(In reply to comment #7)
> There's a nontrivial chance that this is caused by bug 292591, actually... 
> Could someone please check on that?  Things should work as long as the XBL
> that's attached to the page has the system principal, but I wouldn't be that
> suprised if it doesn't in this case...

Does chrome:// xbl have system principals in general?

Comment 11

[Doron Rosenberg (IBM)]

Hmm, aviary branch updated a few minutes ago, I can't reproduce this on
gtk2/linux optimized wiht js turned off and a restart. 

Comment 12

[moz_bug_r_a4]

I'm not sure of C++. Sorry if this is a useless comment.

Keypress events are handled in
"resource://gre/res/builtin/platformHTMLBindings.xml" that is attached to
<html:input> element. But, it seems that current implementation of
nsScriptSecurityManager::CanExecuteScripts does not treat resource: URL as the
special case that should be allowed to run JS.

Comment 13

[Doron Rosenberg (IBM)]

That does sound like a possibility.  Have you tried hacking CanExecuteScripts to
be more linient to see if that works (meaning we have to move the xbl file
probably)?

Comment 14

[moz_bug_r_a4]

I've not tried hacking CanExecuteScripts. But, I've tested the following
situation.

I've copied "<appdir>/res/builtin/platformHTMLBindings.xml" to my chrome
directory, and edited "<appdir>/res/forms.css":

  input {
    ...
    /*-moz-binding:
url("resource://gre/res/builtin/platformHTMLBindings.xml#inputFields");*/
    -moz-binding:
url("chrome://my_test/content/platformHTMLBindings.xml#inputFields");
    ...
  }

then, the arrow keys work good even when JavaScript is disabled.

Comment 15

[Doron Rosenberg (IBM)]

(In reply to comment #14)
> I've not tried hacking CanExecuteScripts. But, I've tested the following
> situation.
> 
> I've copied "<appdir>/res/builtin/platformHTMLBindings.xml" to my chrome
> directory, and edited "<appdir>/res/forms.css":
> 
>   input {
>     ...
>     /*-moz-binding:
> url("resource://gre/res/builtin/platformHTMLBindings.xml#inputFields");*/
>     -moz-binding:
> url("chrome://my_test/content/platformHTMLBindings.xml#inputFields");
>     ...
>   }
> 
> then, the arrow keys work good even when JavaScript is disabled.
> 

We could move the file inside of mozilla so that it gets a chrome url.  Not sure
if we want to preserve the previous behavior of allowing resource:// to run
script in this situation though.

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

IMHO the right fix is to move all neccesary files into chrome. I'd rather limit 
the number of protocols with elevated privileges as much as possible.

Additionally it just seems like a bad idea that we have random files in so 
different paths then the rest.

Comment 17

[Chase Phillips]

Verify that these changes weren't in chrome.  If they were, they weren't moved
out for some security reason.

If both of these check out, let's move as Jonas suggested.

Jonas, can you take this bug?

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It looks like it should be safe to move to chrome. They were moved from chrome
to res in 2000 with the comment "moving bindings into res to eliminate chrome
dependency" (no bugnumber).

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: patch to fix

This should take care of it. It's missing fixes to packages in browser/, mail/
and calendar/, but I don't have those pulled right now. Would be great if
someone could provide patch for those otherwise i'll just pull them too.

Comment 20

[[e-mail]]

Attachment: Alternative approach

Instead of blindly blocking all xbl handlers, only actually block scripts...

Comment 21

[Benjamin Smedberg]

Comment on attachment 187542 [details] [diff] [review]
patch to fix

The global-platform package has special rules that automatically distinguish
between unix/mac/win through the use of subdirectories. I really don't think
this patch will work in toolkit apps. If you s/global-platform/global/ or talk
to me about using the app-specific subdirs, then r=me

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: patch v2

This also includes changes to missing packaging files and a change to use
NS_NewURI instead of SetSpec since setting the spec might not work now that it
can be any uri.

Comment 23

[Johnny Stenback (:jst)]

Comment on attachment 187684 [details] [diff] [review]
patch v2

sr=jst (dveditz, feel free to do an additional once-over on this if you want
to).

Comment 24

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Checked in. Thanks for the quick reviews!

Comment 25

[Jay Patel [:jay]]

Thanks Jonas for the quick patch! Marking fixed on the branches.

Comment 26

[Worcester12345]

Some bugs they minus or remove completely the blocking flag. Thanks for fixing this.

Comment 27

[Jason Daly]

Is this also fixed on the trunk?

Comment 28

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

yes, it wouldn't be marked 'fixed' otherwise

Comment 29

[laniksj]

Will this be fixed on 1.0.x branch.  I'm having the above problem on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050621
Firefox/1.0.5

Comment 30

[Tuukka Tolvanen (sp3000)]

> Will this be fixed on 1.0.x branch.  I'm having the above problem on:

It has been fixed on the 1.0.x branch ('fixed-aviary1.0.5' in keywords)

Comment 31

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

crap, this needs to go on the branches too

Comment 32

[Serge Gautherie (:sgautherie)]

(Based on bug 297136 comment 1, this patch would not be needed in MASv1.7.x branch;
but if you know it is, fine with me.)

Comment 33

[Jay Patel [:jay]]

Comment on attachment 187684 [details] [diff] [review]
patch v2

Sorry Jonas, I though this was +'d already for the branches.  a=jay

Comment 34

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: patch that was checked into aviary branch

Comment 35

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ok, everything should be checked in now. Waiting with marking this fixed until
everything has cycled green

Comment 36

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Marking fixed everywhere. It still hasn't cycled on the 1.7 tinderboxes, but i
feel fairly certain it's ok.

Comment 37

[Simon Fraser [no longer active]]

This broke the camino 1.7 branch tinderbox.

Comment 38

[[e-mail]]

*** Bug 297136 has been marked as a duplicate of this bug. ***

Comment 39

[Scott MacGregor]

Jonas, is there any chance this patch with the html bindings could have caused
us to stop doing html symbol replacement? Around the time this patch landed on
the trunk and the branch (Thunderbird), the credits page found under Help /
About began showing an entity error for the trade mark symbol:

Error: undefined entity
Source File: 
jar:file:///C:/PROGRA~1/MOZILL~1/chrome/messenger.jar!/content/messenger/credits
.xhtml
Line: 163, Column: 42
Source Code:
        <h2 class="title">&brandFullName;&trade;

It's as if we are no longer trying to do entity replacement for HTML symbols.

This was the only checkin that went into the branch that looked at all related
which is why I thought I'd ask.

Comment 40

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I can't think of any reason that it should. The only way I can think of that
happening is if the DTD file lived in dist/res/builtin, since I killed that
directory. But it does't look like any of the related files live anywhere nere
there.