issues with typeless object elements used for JS prefetching

[al_9x]

Amazon pages are using dynamically added typeless object elements to prefetch scripts and stylesheets. AFAICT, gecko does not execute/interpret JS and CSS loaded by <OBJECT>, it simply displays them as a text/plain iframe, so I guess this does serve the prefecthing/caching purpose. Here is a test page:

Code: Select all

<script>
addEventListener('load', function() {
	var o =  document.createElement("object");
	o.data = '<external javascript url>';
	document.body.appendChild(o);
}, false);
</script>

There are some NS related issues with this.

1. The most significant: when NS blocks this object it keeps the page in perpetually loading state. This does not happen on first load after clearing cache, so just reload.
2. NoScript sniffs the mime and displays it (and the corresponding icon) in the placeholder and the blocked objects menu. This is misleading for JS and CSS (and whatever else gecko coerces to text/plain) They should be shown as what they'll actually be, text/plain.
3. If you activate this blocked object, it's domain is added to the NS menu. Since it's plain text, is there a need? This also applies to iframes with text/plain content.

[al_9x]

Perhaps placeholders for such objects (non text/plain that are coerced to text/plain) should be hidden.

[Giorgio Maone]

Not sure, this issue needs to be evaluated very carefully.
Mishandling OBJECT elements is a primary source of blocking bypasses (see FlashBlock weaknesses, for instance).

[al_9x]

Not sure, this issue needs to be evaluated very carefully.
Mishandling OBJECT elements is a primary source of blocking bypasses (see FlashBlock weaknesses, for instance).

It's not clear to what you are referring ("not sure")

The main thing here is perpetual loading. Can you repro? The secondary issues:

1. The mime type shown: clearly JS and CSS is misleading, makes it seem like real script and css is blocked, all types that are coerced to text/plain should be shown as such
2. keeping text/plain domains from the menu: makes sense to only put things in the menu that impact the page, whitelisting a text/plain domain is pointless.
3. hiding such placeholders: this depends on whether or not anyone could conceivably use such typeless objects (with a non text/plain url that's coerced to text/plain) for anything other than prefetching/caching. If not, then they should be hidden.

[Giorgio Maone]

The mime type shown: clearly JS and CSS is misleading, makes it seem like real script and css is blocked, all types that are coerced to text/plain should be shown as such

There's no "coercion" happening here: simply, if the content is not a "document" (HTML or XML) and cannot be rendered by a plugin, the object elements tries to render it as text.
But the content type remains the same, and in fact if you try the following:

Code: Select all

data:text/html,<object data="http://www.informaction.com/ia.js"></object>

and right-click, "View frame info", you'll see the type inferred internally by Gecko is "application/x-javascript". I've got no way to tell whether a certain type is rendered as plain text or not.

[al_9x]

I've got no way to tell whether a certain type is rendered as plain text or not.

I think you know that both script and css will be rendered as plain text, are you saying there are exceptions to that? Currently the ui shows blocked script and css objects, which is misleading and confusing, since in fact, no script and css is blocked. However the main issue here, is the loading state, which I can repro with 100% reliability with the test page above, and you?

[jrredho]

Hey Guys,

I cannot contribute to this discussion in a technical way, but I must say: Visiting amazon.com using NoScript 2.0.7/FF 3.6.12 (but, really, this has been happening for some time now) is brutal. I'm in a constant state of page reload. I have to click the stop button continually in the hopes that it will stop the reload at a point where the primary content (the item I'm looking at) is displayed. This behavior isn't present without noscript running.

Can either of you figure out a workaround other than disabling NS prior to visiting amazon.com?

many thanks,
john

[Giorgio Maone]

@al_9x:
No, I cannot reproduce the "perpetually loading" issue.
I'd love to see a reduced test case.
The other, presentation-level, issues are WONTFIX, because there may theoretically be legitimate use cases (e.g. a "show source" frame) which would be hindered, and potential ways to implement this wrong.

@jrredho:
the issue you're reporting sounds different. al_9x didn't talk about "reload", he said the page never appears to stop loading (but is otherwise usable).
Can you reproduce on a clean profile with just NoScript installed?
If you cannot, please try Standard Diagnostic with NoScript enabled, because it might be a conflict with a 2nd extension.

[al_9x]

@al_9x:
No, I cannot reproduce the "perpetually loading" issue.
I'd love to see a reduced test case.

The reduced test page is in the first post.

1. start with a new profile (Fx 3.6.12, NS 2.0.8rc3)
2. add the "activity indicator" spinner to the UI from the toolbar customization palette
3. forbid iframe, apply to trusted
4. load the following page locally:

   Code: Select all

   <script>
   addEventListener('load', function() {
   	var o =  document.createElement("object");
   	o.data = 'http://ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js';
   	document.body.appendChild(o);
   }, false);
   </script>
   

5. allow it
6. when the page reloads, it never finishes, activity indicator continues to spin and the progress bar in the status bar is showing beginning progress
7. reloading the page produces the same behavior with 100% reliability for me.

[al_9x]

The other, presentation-level, issues are WONTFIX, because there may theoretically be legitimate use cases (e.g. a "show source" frame) which would be hindered, and potential ways to implement this wrong.

That appears to be an argument against hiding the placeholders, I won't argue this. But showing the js mime type for something that will be rendered as plain text is misleading, do you not agree?

[Giorgio Maone]

showing the js mime type for something that will be rendered as plain text is misleading, do you not agree?

Showing it as "plain/text" is equally misleading, since the actual mime type is different.
BTW, if a plugin gets registered for JavaScript or CSS mime types (e.g. an inline CSS editor), they won't actually be rendered as text, but they will fire that plugin.
I know it's a very theoretical scenario, but still possible.

[al_9x]

Did you try the reduced test case?

[Giorgio Maone]

Did you try the reduced test case?

Yes I did (it was actually unnoticeable without the activity indicator).
Since no network activity is actually happening, this hints at a request which has been added to the document's loadgroup but never removed.
Probably a bug in Necko which nobody has interest at pinning at fixing: I'll have to look for a work-around.

[al_9x]

Did you try the reduced test case?

Yes I did (it was actually unnoticeable without the activity indicator).

The progress bar in the status bar also indicates an incomplete state, it's supposed to disappear when the navigation is done.

[Giorgio Maone]

Probably a bug in Necko which nobody has interest at pinning at fixing: I'll have to look for a work-around.

BTW, it does not appear to happen on Minefield (which seems to confirm my suspect).