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

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

Discovered independently using a GTK1 Suite build.

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

I see this in Camino, too. Option-delete (for delete-word) doesn't work with JavaScript disabled, either. (Also, Hardware -> 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...

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.

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?

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

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.

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

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

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

Checked in. Thanks for the quick reviews!

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

(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

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.

This broke the camino 1.7 branch tinderbox.

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

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.