Closed Bug 1024632 Opened 10 years ago Closed 7 years ago

need a way to distinguish (ignore) DOM events from synthetic 'about:blank' document

Categories

(Add-on SDK Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: zombie, Unassigned)

References

Details

for e10s, we are switching to using frame scripts for tab content events in bug 1023326. this is my understanding of what is happening (from bz's bug 993015 comment 11): firefox keeps a cached, pre-loaded, synthetic 'about:blank' document in each window. when a new tab is opened, it gets linked with this document and DOMWindow, which then navigates to the target url. but when a tab is opened in a new (browser) window, this pre-loaded instance of a blank document doesn't exist, so it is created, and immediately attached to a tab, before the 'about:blank' document is loaded. we then receive content events (DOM ready, loaded) from this tab for the temporary 'about:blank' document, which we shouldn't forward to the addons, because that would be incorrect. i can't distinguish between the above scenario, and the case of actually opening a new tab with 'about:blank' as the _target_ url. is there a property, or some other way, either from the content (frame script) or the chrome (addon SDK) side, to see if the 'about:blank' document is a temporary one, and will be navigated away from moments later, or it is the actual destination? or if it doesn't exist, can we get such a property on, say, docShell? Gabor, do you maybe have any insight on the issue? or know who would?
Flags: needinfo?(gkrizsanits)
(In reply to Tomislav Jovanovic [:zombie] from comment #0) > firefox keeps a cached, pre-loaded, synthetic 'about:blank' document in each > window. when a new tab is opened, it gets linked with this document and > DOMWindow, which then navigates to the target url. Matteo was asking about this in irc, so i'll try to clarify: it is my understanding that platform always has one pre-loaded about:blank document in reserve, presumably to speed-up opening a new tab, _except_ when it's opening in a new window. (i'm able to observe the creation of this document using frame scripts loaded by the global message manager).
Gabor seems to be on PTO.. Boris, can you maybe provide some insight on this issue?
Flags: needinfo?(gkrizsanits) → needinfo?(bzbarsky)
> firefox keeps a cached, pre-loaded, synthetic 'about:blank' document in each window. Not quite. What happens in our implementation right now is one of two things: 1) An iframe (or tab) with no src set will start loading an about:blank document. 2) If someone tries to get the window out of a docshell before it's ever loaded a window it will synchronously synthesize an about:blank document and corresponding window and return that window. If this happens while the initial load for the docshell is in progress and the document that load results in is same-origin with the about:blank we synthesized, the new document will use the same window as the one we created for the about:blank document. Items #1 and #2 are somewhat independent. Are you seeing notifications for the synthetic document #2 creates, or for the document #1 loads? Note that our current behavior doesn't quite match the spec in all sorts of ways, so relying on its details is probably not a great idea either; we want to change it.
Flags: needinfo?(bzbarsky)
Also note that there are cases in which the document created by #2 is in fact what will end up getting rendered. Most simply, a testcase like so: <body><script> var ifr = document.createElement("iframe"); ifr.src = "http://example.com"; document.body.appendChild(ifr); ifr.contentDocument.write("hey"); ifr.contentDocument.close(); </script>
(In reply to Boris Zbarsky [:bz] from comment #3) > 1) An iframe (or tab) with no src set will start loading an about:blank document. or a tab opened with the explicit target URI of "about:blank". > Are you seeing notifications for the synthetic document #2 creates, or for > the document #1 loads? i'm seeing notifications/events from both cases, but i want to distinguish between them, because i need to ignore DOM events from about:blank document created in the #2 case. > Note that our current behavior doesn't quite match the spec in all sorts of > ways, so relying on its details is probably not a great idea either; we want > to change it. yeah, that's why we need to get this right, and not rely on lucky event ordering like we currently do.
Flags: needinfo?(bzbarsky)
> because i need to ignore DOM events from about:blank document created in the #2 case Why are you getting DOM events from #2? That's a bit unexpected. Can you attach a C++ stack from such an event here?
Flags: needinfo?(bzbarsky)
(In reply to Boris Zbarsky [:bz] from comment #6) > Why are you getting DOM events from #2? That's a bit unexpected. Can you > attach a C++ stack from such an event here? i don't really know how to get that.. there is a patch in bug 1023326, and here is a line that hacks around the problem: https://github.com/mozilla/addon-sdk/pull/1510#discussion_r13788916 if you remove that hack, and run cfx testpkgs -f tabs$:OpenInNewWindow$ -o -v -b \Nightly\firefox.exe the test fails because it gets DOMContentLoaded event from the about:blank document. sorry if these STR are too inconvenient for you. please tell me if that is a problem, i can try to reduce it to minimal test case that doesn't depend on SDK (traits) code for tabs and windows, which is awfully complicated (i didn't want to try and do that unless it's required, because this problem might depend on the exact ordering tab and content events, which might be hard to replicate with a reduced test case).
Flags: needinfo?(bzbarsky)
> i don't really know how to get that.. The simplest way is to put a call to Math.sin() in the relevant JS, then run your test under a C++ debugger, breakpoint in js::math_sin, and when the breakpoint is hit look at the C++ stack. I'm not going to have time to do any debugging here for probably at least a week, since I have pending review requests that will take at least that long, so if you want me to do that, you'll have to wait a while...
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bzbarsky)
(In reply to Boris Zbarsky [:bz] from comment #8) > I'm not going to have time to do any debugging here for probably at least a > week, since I have pending review requests that will take at least that > long, so if you want me to do that, you'll have to wait a while... I will do that.
(In reply to Tomislav Jovanovic [:zombie] from comment #7) > if you remove that hack, and run > All 5 tests passed for me with that line removed... I'm on linux if that mattes.
Gabor, thanks!
Flags: needinfo?(bzbarsky)
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #10) > All 5 tests passed for me with that line removed... I'm on linux if that > mattes. well, that's sure to make things complicated.. :\ can you please run all the windows and tab tests with: -f "tab|win"
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #9) > I will do that. and also, thank you! ;)
(In reply to Tomislav Jovanovic [:zombie] from comment #12) > can you please run all the windows and tab tests with: -f "tab|win" Since I have never been able to run all the jetpack tests locally without a bunch of failures, could you tell me what I'm looking for exactly? I see a bunch of failures typically: console.error: addon-sdk: fail: Should not be any unexpected windows open console.trace: addon-sdk: _ecated/unit-test.js 89 fail _ecated/unit-test.js 293 done _js.path/sdk/test.js 79 _/Promise-backend.js 863 Handler.prototype.process _/Promise-backend.js 742 this.PromiseWalker.walkerLoop 0 console.error: addon-sdk: fail: Should not be any unexpected tabs open console.trace: addon-sdk: _ecated/unit-test.js 89 fail _ecated/unit-test.js 295 done _js.path/sdk/test.js 79 _/Promise-backend.js 863 Handler.prototype.process _/Promise-backend.js 742 this.PromiseWalker.walkerLoop 0 I think the best would be if you could ping me sometime on irc and then we can try to hunt this down together :)
Priority: P1 → --
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.