Last Comment Bug 789278 - XHR from Scriptish user script started failing (response object properties undefined)
: XHR from Scriptish user script started failing (response object properties un...
Status: RESOLVED FIXED
: addon-compat, regression
Product: Core
Classification: Components
Component: General (show other bugs)
: 17 Branch
: x86 Mac OS X
: -- normal (vote)
: mozilla18
Assigned To: Erik Vold [:erikvold] (please needinfo? me)
:
:
Mentors:
Depends on:
Blocks: 553102
  Show dependency treegraph
 
Reported: 2012-09-06 13:55 PDT by Kartikaya Gupta (email:kats@mozilla.com)
Modified: 2012-09-10 16:35 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
affected
-
fixed


Attachments
User script that fails (2.51 KB, text/plain)
2012-09-06 13:55 PDT, Kartikaya Gupta (email:kats@mozilla.com)
no flags Details

Description Kartikaya Gupta (email:kats@mozilla.com) 2012-09-06 13:55:43 PDT
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.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2012-09-06 19:00:39 PDT
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.
Comment 2 Bobby Holley (:bholley) (busy with Stylo) 2012-09-06 23:02:15 PDT
(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/
Comment 3 Wes Kocher (:KWierso) 2012-09-06 23:07:42 PDT
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
Comment 4 Kartikaya Gupta (email:kats@mozilla.com) 2012-09-07 06:43:57 PDT
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
Comment 5 Erik Vold [:erikvold] (please needinfo? me) 2012-09-07 09:22:01 PDT
Can someone try the Scriptish nightly? http://scriptish.org/downloads/

Some recent commits make me think this issue is resolved.
Comment 6 Wes Kocher (:KWierso) 2012-09-07 09:35:00 PDT
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.
Comment 7 Bobby Holley (:bholley) (busy with Stylo) 2012-09-07 09:49:10 PDT
(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
Comment 8 Kartikaya Gupta (email:kats@mozilla.com) 2012-09-07 10:14:56 PDT
(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.
Comment 9 Erik Vold [:erikvold] (please needinfo? me) 2012-09-07 10:24:17 PDT
This should be fixed by https://github.com/scriptish/scriptish/commit/46d342a41a31b1c84ac808de48a21478680b932b try nightly tomorrow.
Comment 10 Kartikaya Gupta (email:kats@mozilla.com) 2012-09-07 10:51:01 PDT
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.

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