The default bug view has changed. See this FAQ.

XHR from Scriptish user script started failing (response object properties undefined)

RESOLVED FIXED in Firefox 18

Status

()

Core
General
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: kats, Assigned: erikvold)

Tracking

({addon-compat, regression})

17 Branch
mozilla18
x86
Mac OS X
addon-compat, regression
Points:
---

Firefox Tracking Flags

(firefox17- affected, firefox18- fixed)

Details

Attachments

(1 attachment)

Created attachment 658991 [details]
User script that fails

Dropping this bug in Core:General because I'm not sure where it belongs, really.

Basically I have Scriptish (the new fork of GreaseMonkey) installed with a user script that does some XHR stuff. It worked fine on Aurora 16 but recently I upgraded to Aurora 17 and it broke. I used the mozregression tool to narrow the regression down to this range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=812ea773f166&tochange=8c85c83068e7

Steps to reproduce:
1) Start Aurora with a new clean profile
2) Install the Scriptish add-on (and restart Aurora)
3) Install the attached user script into Scriptish
4) Go to any Bugzilla bug list page (e.g. https://bugzilla.mozilla.org/buglist.cgi?short_desc=XHR;resolution=---;resolution=DUPLICATE;query_format=advanced;bug_status=NEW;short_desc_type=allwordssubstr)

Expected results:
Once the page is loaded and the user script runs, the word "dummy" appears in small blue text to the left of each bug description (assuming you haven't fiddled too much with the layout of the bugzilla page)

Actual results:
Bugzilla results page doesn't have the "dummy" text, and there is an error in the Error console indicating that the responseJSON property on the scriptish response object doesn't exist.
status-firefox17: --- → affected
status-firefox18: --- → affected
Bobby, could this be fallout from the __exposedProps__ thing?  If the GM_xmlhttpRequest runs in chrome but the user script is in content, seems like it could.
Blocks: 553102
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
Keywords: addon-compat
(In reply to Boris Zbarsky (:bz) from comment #1)
> Bobby, could this be fallout from the __exposedProps__ thing?  If the
> GM_xmlhttpRequest runs in chrome but the user script is in content, seems
> like it could.

If this regressed in that range, it's almost certainly the culprit. See this blog post for how to fix the script:

https://blog.mozilla.org/addons/2012/08/20/exposing-objects-to-content-safely/
Scriptish issue tracker has a bug filed for this: https://scriptish.lighthouseapp.com/projects/83146/tickets/624-regression-in-nightly-due-to-lack-of-__exposedprops__#ticket-624-2
The Scriptish code in question [1] already has the __exposedProps__ defined, it just doesn't define anything on responseJSON and responseXML. There's a comment that says "can't support responseXML because security won't let the browser call properties on it" - it looks like if you're trying to expose a object with nested sub-objects to content, you have to have an __exposedProps__ field on each of those nested objects, is that correct? Is there some way to mark an entire tree of objects accessible to content? Otherwise I think this will break a lot of user scripts.

[1] https://github.com/scriptish/scriptish/blob/master/extension/modules/api/GM_xmlhttpRequester.js#L202
Can someone try the Scriptish nightly? http://scriptish.org/downloads/

Some recent commits make me think this issue is resolved.
With Scriptish nightly, on Firefox Nightly, running the attached script shows the following in the error console:
[Scriptish] /testscript: Sending request for bugs 282547,395625,402723,411571,434836,435876,447689,460460,478444,509556,522463,557735,560152,563399,567432,567632,571013,579607,584382,584396,602518,607128,610943,611320,630089,641618,641804,651497,655725,657000,661604,664720,668948,673458,677300,678070,684722,686828,695605,700629,700640,704102,704787,707484,708450,709991,714751,715470,716133,716491,716765,717562,717566,721336,721651,721946,721949,724188,729109,730177,734436,739037,742181,742259,748086,749372,753981,754941,757888,759624,760041,762598,765206,767102,775476,776239,779707,783716,788594,789278

Timestamp: 9/7/2012 9:30:54 AM
Error: [testscript] TypeError: response is undefined
Source File: file:///C:/Users/KWierso/AppData/Roaming/Mozilla/Firefox/Profiles/5kdy1o85.default/scriptish_scripts/testscript/testscript.user.js
Line: 34



And I don't see anything being added to the bug list.
(In reply to Kartikaya Gupta (:kats) from comment #4)
> it looks like if you're trying to expose a
> object with nested sub-objects to content, you have to have an
> __exposedProps__ field on each of those nested objects, is that correct? Is
> there some way to mark an entire tree of objects accessible to content?
> Otherwise I think this will break a lot of user scripts.

It has to be done to each sub-object, but you can write a function to do it. Here's a function that I wrote to do it for the BrowserElement API. Feel free to crib it.

http://mxr.mozilla.org/mozilla-central/source/dom/browser-element/BrowserElementParent.js#32
(In reply to Wes Kocher (:KWierso) from comment #6)
> With Scriptish nightly, on Firefox Nightly, running the attached script
> shows the following in the error console:


Yeah, I grabbed the latest Scriptish source and tried it, same problem. As a workaround I'm now using responseText (which works) and doing a JSON.parse on it in the user script.

I'll try the exposeAll thing but it really would be nice to have a better way to do that; it seems like walking through the entire tree will be inefficient.
This should be fixed by https://github.com/scriptish/scriptish/commit/46d342a41a31b1c84ac808de48a21478680b932b try nightly tomorrow.
Assignee: nobody → evold
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
That alone will not fix it; you need to expose all of the sub-objects inside the responseJSON as well. However I guess this is a scriptish bug and not a mozilla bug so I'll leave this closed.

Updated

5 years ago
status-firefox18: affected → fixed
Target Milestone: --- → mozilla18
tracking-firefox17: ? → -
tracking-firefox18: ? → -
You need to log in before you can comment on or make changes to this bug.