!@ surrogate not running on iframe when js is enabled

[al_9x]

Simple local web server test page (parent + iframe) Surrogate runs for both when js is disabled, and only for the parent when js enabled

[Giorgio Maone]

Fixed in latest development build, thanks.

[al_9x]

Fixed in latest development build, thanks.

NS 2.0.1

1. Hotmail inbox iframe (.mail.live.com/mail/InboxLight.aspx)
   1. @ - not firing
   2. !@ - not firing
2. Simple localhost page with scripting on (ok when off)
   test.htm

   Code: Select all

   <iframe src="frame.htm"></iframe>
   

   frame.htm

   Code: Select all

   iframe
   

   Code: Select all

   noscript.surrogate.test.replacement;dump('test surrogate - '+document.URL+'\n');
   noscript.surrogate.test.sources;!@localhost
   

   1. !@ - not firing for the iframe, but does fire on ctrl-f5
   2. @ - ok, though there is a slight difference (for the iframe) between f5 (dumps about:blank) and ctrl-f5 (dumps frame.htm) Is that a problem?

[Giorgio Maone]

I tested with http://evil.hackademix.net/test/surrogate/frames.php and
noscript.surrogate.test.sources

Code: Select all

!@http://evil.hackademix.net/test/surrogate/frames.php

noscript.surrogate.test.replacement

Code: Select all

document.write = function(s){ if(arguments[0]=="FAILED") arguments[0]="OK";  document.__proto__.write.apply(this, arguments)  };var res=document.getElementById("res");if(res)res.innerHTML="OK";

It worked as expected on Minefield: "Before parsing: OK" when the selector is just "@", "On document load: OK" when the selector contains "!".

Actually I'm finding results are not consistent on Fx 3.6.x, and probably some caching-related issue is at work as well.
Investigating...

[al_9x]

I tried you test page and everything works, even the dumped urls in the @ case are the same for f5 and ctrl-f5. However, both the localhost test that I posted as well as hotmail, don't work, in the manner described in my previous post.

[Giorgio Maone]

However, both the localhost test that I posted as well as hotmail, don't work, in the manner described in my previous post.

On Minefield as well?

[al_9x]

However, both the localhost test that I posted as well as hotmail, don't work, in the manner described in my previous post.

On Minefield as well?

Just tried in "Mozilla/5.0 (Windows NT 5.1; rv:2.0b4pre) Gecko/20100806 Minefield/4.0b4pre"

My local page is ok, hotmail doesn't work in minefield at all so can't test that.

[Giorgio Maone]

Should be definitely fixed in latest development build for Firefox 3.6.8 and above (including 4).
I'm dropping page-level surrogate support in frames on older Firefox versions: it just seems there's no reliable way to execute them at the right time.

[al_9x]

Should be definitely fixed in latest development build for Firefox 3.6.8 and above (including 4).
I'm dropping page-level surrogate support in frames on older Firefox versions: it just seems there's no reliable way to execute them at the right time.

I think there is still a problem in Hotmail. @.mail.live.com/mail/InboxLight.aspx surrogate is being invoked when selecting messages. AFAICT message selection does not navigate the InboxLight.aspx iframe, it does ajax, so the surrogate should not be called.

This may be related to: http://forums.informaction.com/viewtopi ... =10&t=4733

[Giorgio Maone]

I think there is still a problem in Hotmail. @.mail.live.com/mail/InboxLight.aspx surrogate is being invoked when selecting messages. AFAICT message selection does not navigate the InboxLight.aspx iframe, it does ajax, so the surrogate should not be called.

Page-level surrogates in on Fx 3.6.8 and above are triggered by a content-document-global-created notification observer, therefore if you're positive they're invoked after an AJAX navigation (which I doubt) or twice or at the wrong time, a bug should be filed on the Mozilla bug tracker blocking https://bugzilla.mozilla.org/show_bug.cgi?id=549539

[al_9x]

if you're positive they're invoked after an AJAX navigation (which I doubt)

Can you please confirm that it is indeed gecko? You have a hotmail account. Make sure you have the preview pane activated. Click on different messages in the inbox.

Code: Select all

noscript.surrogate.test.replacement;dump('test surrogate - '+document.URL+'\n');
noscript.surrogate.test.sources;@.mail.live.com/mail/InboxLight.aspx

[Giorgio Maone]

I do not think is a bug.
That page is used exclusively to maintain navigation history state among AJAX loads, therefore it gets manipulated (using document.open() + document.write(), probably, but I'm not sure) in order to create a history item by emulating a page refresh without generating network traffic.
Therefore, since the JavaScript global object gets teared down and recreated each time, both Gecko's and NoScript's behavior are correct (running the page-level surrogate).
You can verify the JS global object is always new by running the following as your test surrogate replacement:

Code: Select all

dump("Context is " + (("test" in window) ? "OLD" : "NEW") + "!\n"); window.test = true;

[al_9x]

Those subsequent surrogate invocations (upon message selection) appear to be executing in the context of the wrong <iframe>

1. Change the surrogate to:

   Code: Select all

   addEventListener('load',function(){dump('test surrogate - '+parent.name+'\n');alert(document.documentElement.innerHTML);},false);
   

2. Notice the very short content, just a single <pre> in the body
3. Using dom inspector, search for the pre tag, you will find it in the historyFrame iframe which is inside the InboxLight.aspx iframe
4. parent.name also confirms that you are inside the child of the intended <iframe>
5. so somehow the surrogate intended for the parent frame is executing for the child

[Giorgio Maone]

[*] so somehow the surrogate intended for the parent frame is executing for the child[/list]

If the frame is empty (no src attribute or just the default about:blank) and it's written with document.write(), it "inherits" its document URL by its parent. Might this explain your observations?

[al_9x]

Might this explain your observations?

Let's say that it does, dom inspector confirms that the document.URL of the child history iframe changes to that of the parent after message selection. The purpose of surrogates being more often than not, dom manipulation, it seems a worthwhile goal to try to avoid executing them in the wrong/unintended frames. Is there a reliable way to detect this url inheriting (cross document doc.writing ) to avoid executing the surrogate? Or would you say one might actually want surrogates firing on cross doc.written frames?