what scenarios need @ surrogates to run when JS is disabled

[al_9x]

My understanding is that the ability to execute when JavaScript is disabled was added later. I guess cookie manipulation is one reason? Are there others?

[Giorgio Maone]

http://forums.informaction.com/viewtopic.php?f=7&t=4542
Imagebam and Imagehaven don't even show any image without the surrogates, unless you enable JS.
More generally speaking, they're useful to provide functionality which would require enabling JS otherwise.

[al_9x]

Thanks, got it, it's for dom manipulation that would normally be done by content script. Is "!@" just shorthand for "@" which attaches a DOMContentLoaded?

[Giorgio Maone]

Thanks, got it, it's for dom manipulation that would normally be done by content script. Is "!@" just shorthand for "@" which attaches a DOMContentLoaded?

And runs both when scripts are enabled and disabled ("!" alone runs on disabled pages only).

[al_9x]

There is still some confusion

1. I was under the impression at the time of the first post, that "@" surrogates ran with JS disabled. It turns out that behavior started in .20 stopped in .39 and just restarted in .96. Please clarify, what's intended.
2. As of 1.9.9.91 "@*" stopped running on about: pages. Bug or design?
3. even prior to 1.9.9.91 "@*" didn't run on about:blank. Bug or design?
4. Would be nice to have a surrogate reference section on your site, documenting all the types, when they run in page life-cycle, under what conditions(script, etc), and if any urls are excluded from matching. Perhaps a wiki would be useful, there is a lot of information dispersed across two forums, blog, faq, changelog, features

[Giorgio Maone]

I was under the impression at the time of the first post, that "@" surrogates ran with JS disabled. It turns out that behavior started in .20 stopped in .39 and just restarted in .96. Please clarify, what's intended.

@ surrogates have been running with JS disabled for some versions as a side effect of using Components.utils.Sandbox.
Currently Sandbox is used only for ! and !@ surrogates, while DOM injection is used for @ and inclusion surrogate, allowing to play with expandos, content functions and prototypes.

As of 1.9.9.91 "@*" stopped running on about: pages. Bug or design?

By design, as a side effect of a better timing strategy for framed pages.

even prior to 1.9.9.91 "@*" didn't run on about:blank. Bug or design?

Gecko bug/limitation

[al_9x]

@ surrogates have been running with JS disabled for some versions as a side effect of using Components.utils.Sandbox.
Currently Sandbox is used only for ! and !@ surrogates, while DOM injection is used for @ and inclusion surrogate, allowing to play with expandos, content functions and prototypes.

I must be misunderstanding. It appears you're saying that @ surrogates used to run with JS disabled, due to the Sandbox, but no longer do (intentionally), since you switched to DOM injection. But I am observing the exact opposite. @ surrogates did not run with JS disabled from .39 to .95 and just started in .96. So again, are @ surrogates supposed to run with JS disabled or not?

As of 1.9.9.91 "@*" stopped running on about: pages. Bug or design?

By design, as a side effect of a better timing strategy for framed pages.

I don't understand, in another thread you said that "@*" was intended to match all urls, including chrome: and about:, so why should "a better timing strategy" now prevent execution on about: urls?

[Giorgio Maone]

@ surrogates did not run with JS disabled from .39 to .95 and just started in .96. So again, are @ surrogates supposed to run with JS disabled or not?

I don't know how you're observing that. "@" surrogate have not been running on JS disabled pages for a long time, and they still do not. "!@" (or "@!") and "!" surrogates do.

I don't understand, in another thread you said that "@*" was intended to match all urls, including chrome: and about:, so why should "a better timing strategy" now prevent execution on about: urls?

Implementation details. Matching all URLs was nice, but not that useful. Being able to run before the DOM was parsed was much more important, and at this moment it can be consistently made across frame for HTTP URLs only.

[al_9x]

I don't know how you're observing that.

If you're referring to @ surrogates running on JS disabled pages in .96, then very simply, with a test surrogate:

Code: Select all

noscript.surrogate.test.replacement=alert('test surrogate');
noscript.surrogate.test.sources=@*

and it does alert on non whitelisted pages, in .95 it doesn't

[Giorgio Maone]

Mmm, that's correct. My test page (for all the types, together) had a bug
However, that's not how's intended to work.

[Giorgio Maone]

Fixed in latest development build