Closed Bug 296764 Opened 15 years ago Closed 15 years ago

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

Categories

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

defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.8beta3

People

(Reporter: mcm.ham, Assigned: sicking)

References

Details

(Keywords: fixed-aviary1.0.5, fixed1.7.9, regression, Whiteboard: [cb])

Attachments

(3 files, 1 obsolete file)

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.
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
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Works with 2005-06-02 build, reporter says it fails with 2005-06-03 build.
Could this be a regression from fixing bug 292464?
Severity: normal → major
Flags: blocking1.8b3?
Keywords: regression
Blocks: 297136
Discovered independently using a GTK1 Suite build.
OS: Windows XP → All
Flags: blocking-aviary1.1?
I see this in Camino, too. Option-delete (for delete-word) doesn't work with
JavaScript disabled, either.

(Also, Hardware -> All)
Hardware: PC → Macintosh
Hardware: Macintosh → All
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...
Blocks: 292464, 292591
Flags: blocking1.7.9?
Flags: blocking-aviary1.0.5?
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.
Flags: blocking1.8b3?
Flags: blocking1.8b3+
Flags: blocking1.7.9?
Flags: blocking1.7.9+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0.5?
Flags: blocking-aviary1.0.5+
doron, aaron: do you understand how this bug could be happening? (asking on
behalf of 1.0.5 meeting)
(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?
Hmm, aviary branch updated a few minutes ago, I can't reproduce this on
gtk2/linux optimized wiht js turned off and a restart. 
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.
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)?
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.
(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.
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.
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?
Assignee: events → bugmail
Whiteboard: [cb] no progress for 1.8b3?
Whiteboard: [cb] no progress for 1.8b3? → [cb] has theoretical solution, needs patch
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).
Attached patch patch to fix (obsolete) — Splinter Review
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.
Attachment #187542 - Flags: superreview?(benjamin)
Attachment #187542 - Flags: review?(benjamin)
Instead of blindly blocking all xbl handlers, only actually block scripts...
Whiteboard: [cb] has theoretical solution, needs patch → [cb] has patches, needs review
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
Attachment #187542 - Flags: superreview?(benjamin)
Attachment #187542 - Flags: review?(benjamin)
Attachment #187542 - Flags: review-
Attached patch patch v2Splinter Review
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.
Attachment #187542 - Attachment is obsolete: true
Attachment #187684 - Flags: superreview?(benjamin)
Attachment #187684 - Flags: review?(benjamin)
Attachment #187684 - Flags: superreview?(benjamin)
Attachment #187684 - Flags: review?(benjamin)
Attachment #187684 - Flags: review+
Attachment #187684 - Flags: approval1.8b3+
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).
Attachment #187684 - Flags: superreview?(dveditz) → superreview+
Checked in. Thanks for the quick reviews!
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Thanks Jonas for the quick patch! Marking fixed on the branches.
Some bugs they minus or remove completely the blocking flag. Thanks for fixing this.
Is this also fixed on the trunk?
yes, it wouldn't be marked 'fixed' otherwise
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
> 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)
crap, this needs to go on the branches too
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #187684 - Flags: approval1.7.9?
Attachment #187684 - Flags: approval-aviary1.0.5?
(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 on attachment 187684 [details] [diff] [review]
patch v2

Sorry Jonas, I though this was +'d already for the branches.  a=jay
Attachment #187684 - Flags: approval1.7.9?
Attachment #187684 - Flags: approval1.7.9+
Attachment #187684 - Flags: approval-aviary1.0.5?
Attachment #187684 - Flags: approval-aviary1.0.5+
Ok, everything should be checked in now. Waiting with marking this fixed until
everything has cycled green
Marking fixed everywhere. It still hasn't cycled on the 1.7 tinderboxes, but i
feel fairly certain it's ok.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Keywords: fixed1.7.9
Resolution: --- → FIXED
This broke the camino 1.7 branch tinderbox.
No longer blocks: 297136
*** Bug 297136 has been marked as a duplicate of this bug. ***
Whiteboard: [cb] has patches, needs review → [cb]
Target Milestone: --- → mozilla1.8beta3
Blocks: 299473
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.
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.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.