InformAction Forums

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

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.

Giorgio Maone wrote: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).

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.

al_9x wrote: 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

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

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

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

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.

Giorgio Maone wrote: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.

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

al_9x wrote:Did you try the reduced test case?

Giorgio Maone wrote:

al_9x wrote:Did you try the reduced test case?

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

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