Consider wrapping content scripts in a function so that they may return



Add-on SDK
7 years ago
6 years ago


(Reporter: adw, Unassigned)


Firefox Tracking Flags

(Not tracked)




7 years ago
A few weeks ago cherenkov pinged me on IRC because he was trying to do this in a page mod content script:

  if (!someCriterion())
  // else, continue on with page mod...

Of course the return statement doesn't make sense, since content scripts aren't wrapped in a function when they're evaluated.  I pointed out that he could easily write his code with using return, but he said Greasemonkey scripts are allowed to return [1], kind of like a system.exit() or something, so on that basis I told him I'd file an RFE.

I don't necessarily agree that we should support this, but since Greasemonkey does (apparently, I don't know the details), maybe we should consider it.


Comment 1

7 years ago
(In reply to comment #0)
> I pointed out that he could easily write his code with using return

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".
Component: Jetpack SDK → General
Product: Mozilla Labs → Add-on SDK
QA Contact: jetpack-sdk → general
Version: Trunk → unspecified
If you read current greasemonkey source code,
it doesn't seems to be true anymore:
The result of evalInSandbox is not used and content script is wrapped in an anonymous function without store its result.

I suggest a WONTFIX for this bug as postMessage allow send values to the addon script.
In triage conversation, folks agreed that this would be useful to support, although it isn't a high priority.
Priority: -- → P3
Target Milestone: --- → 1.0
Why not just write content script as self executable function ??

(function() {})();

And you have a return.

Also I think having return encourages bad design, so I'm pretty much opposite to this feature. Just saying.
(automatic reprioritization of 1.0 bugs)
Priority: P3 → P2
Target Milestone: 1.0 → 1.1
Marking anything that potentially looks like a feature request as "enhancement", sorry for the bugspam. :)
Severity: normal → enhancement
Re-prioritizing all 1.1-targeted feature requests to 1.2.
Target Milestone: 1.1 → 1.2
(Pushing all open bugs to the --- milestone for the new triage system)
Target Milestone: 1.2 → ---
This hasn't been really touched for 7 months and no one really seems to want it, so I'm going to close this as WONTFIX.

Feel free to override me if you still want this. :)
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.