[FIXED] bookmarklets cannot add event listeners (Fx 27)

[porl]

In Firefox 27.0 (Linux), a bookmarklet will no longer add an event listener to a document unless scripts are enabled for the host domain. This makes it impossible to navigate/modify a page using custom mouse or keyboard actions (zoom, drag, direction keys, etc) without a reload. NoScript 2.6.8.13 worked OK with the previous FF, but this behaviour breaks a large number of the bookmarklets I typically use, so I'm having to consider enabling all top-level domains.

No errors or indications are given.

[therube]

Example bookmarklet?

[Giorgio Maone]

I can confirm the change in behavior, which seems due to a change in Firefox's internals.
I'm not sure there's any work-around, but I'm looking for it.

[Thrawn]

Can any of the bookmarklets be converted to surrogate scripts? If so, then you can make them run anywhere.

Generally it's just a matter of adding a new preference, noscript.surrogate.<arbitrary name>.sources, set to

Code: Select all

!@*

and then making a second, noscript.surrogate.<name>.replacement, containing the bookmarklet code.

You might even be able to combine multiple bookmarklets in one replacement, depending on how carefully they're written.

[porl]

Can any of the bookmarklets be converted to surrogate scripts?

Thanks, Thrawn, that sounds like a good idea for some of my regular haunts.

On the other hand, I quite often use bookmarklets to modify a page for printing: click to delete page content I don't want printed and put what remains in as tiny a font as I can, so a technical article doesn't run to tens of pages.

In that case I won't know in advance what I want to print and I would prefer not to add that functionality to every site I encounter, however carefully I try to package it.

@therube: I have other uses for event listeners, but the 'click to delete' feature is a good example. At its simplest:

Code: Select all

  (function () {
    document.addEventListener('click', function (ev) {
      var el = ev.target;
      if (el.nodeType == 1 && confirm('Delete ' + el.tagName + '?')) {
        el.parentNode.removeChild(el);
        ev.stopPropagation();
        ev.preventDefault();
      }
    }, false);
  })()

(with that whitespace, run this in Scratchpad). I've just noticed, NoScript prevents the code running in Scratchpad too unless the domain is allowed scripting.

[Giorgio Maone]

Worked around in latest development build 2.6.8.15rc1.

Notice that I cannot do anything about Scratchpad, WebConsole, Firebug etc., though, because it's been a Firefox JavaScript runtime change rather than a NoScript change: in facts, you can observe the same "regression" also without NoScript, if you just set the javascript.enabled about:config preference to false. I suppose they can either revert the change, if it's not a security issue, or use the same work-around as mine in the places where it's needed, but I suppose bug reports in their own bug trackers are required.

[porl]

Worked around in latest development build 2.6.8.15rc1.

Sorry, Giorgio, I'm not seeing any difference with that version.

[Giorgio Maone]

You're right, I'm not sure why but it seemed to work for me at some stage.
Investigating, but it seems really hard to work-around: looks like they previously checked disablement status only on direct execution script, but now they also do it before running delayed listeners.

[Thrawn]

Can any of the bookmarklets be converted to surrogate scripts?

Thanks, Thrawn, that sounds like a good idea for some of my regular haunts.

On the other hand, I quite often use bookmarklets to modify a page for printing: click to delete page content I don't want printed and put what remains in as tiny a font as I can, so a technical article doesn't run to tens of pages.

In that case I won't know in advance what I want to print and I would prefer not to add that functionality to every site I encounter, however carefully I try to package it.

Well, you might be able to adjust the bookmarklet code to become the onclick handler of a link that the surrogate inserts into the page...
But really this is more of use case for a proper extension. It's not all that hard to get started with one.

[Giorgio Maone]

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=971650

[Giorgio Maone]

Please check latest development build rc2, thank you!

[Thrawn]

So this broke all the built-in surrogates too?

Mozilla really needs to consult the Mozilla Security Group before making changes...oh, wait, that's 404 these days, isn't it?

[Giorgio Maone]

So this broke all the built-in surrogates too?

Nope, only those which used to register event listeners, i.e. none of the built-ins, fortunately.

[porl]

Please check latest development build rc2, thank you!

I'll test it some more over coming days, but it looks like you've solved not only this issue, but http://forums.informaction.com/viewtopi ... 10&t=13040 too, which is great news.

Many thanks.

[porl]

Full marks for re-enabling eventListeners/XHRs but a couple of things are, sadly, lost along the way.

Bookmarklets enabled by NoScript in the new way
- can't return a string of HTML:

Code: Select all

javascript:'<h3>'+new Date()+'</h3>'

- can't use document.write()

This makes it impossible to achieve some things that are really useful, like writing an IFRAME to show the current document alongside something else. The DOM simply won't do this.

It also complicates using a document as an alternative to the console.

These features can only be restored by enabling scripts globally, so the eventListener/XHR problem had less impact on security.

Also it seems Firefox displays neither syntax nor runtime errors for javascript typed into the address bar.

A couple of other small points:

Firefox doesn't properly URL-encode bookmarklets, so the call to decodeURIComponent() at line 4361 of noscriptService.js:

Code: Select all

  ScriptSurrogate.executeSandbox(window.document,
    decodeURIComponent(url.substring("javascript:".length)));

gives 'malformed URI sequence' errors on bookmarklets that contain '%'s that weren't (manually) escaped. You could test for

Code: Select all

/%[0-9A-F]2/i

before doing that call, because a user may have escaped some '%'s to avoid syntax errors.

Incidentally, I notice the alert text for 'Allow Scripts Globally' contains "\\n" instead of "\n".