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)
Add-on SDK Graveyard
General
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)
Priority: -- → P1
Reporter | ||
Comment 1•10 years ago
|
||
(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).
Reporter | ||
Comment 2•10 years ago
|
||
Gabor seems to be on PTO.. Boris, can you maybe provide some insight on this issue?
Flags: needinfo?(gkrizsanits) → needinfo?(bzbarsky)
Comment 3•10 years ago
|
||
> 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)
Comment 4•10 years ago
|
||
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>
Reporter | ||
Comment 5•10 years ago
|
||
(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)
Comment 6•10 years ago
|
||
> 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)
Reporter | ||
Comment 7•10 years ago
|
||
(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).
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(bzbarsky)
Comment 8•10 years ago
|
||
> 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)
Updated•10 years ago
|
Flags: needinfo?(bzbarsky)
Comment 9•10 years ago
|
||
(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.
Comment 10•10 years ago
|
||
(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.
Reporter | ||
Comment 12•10 years ago
|
||
(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"
Reporter | ||
Comment 13•10 years ago
|
||
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #9)
> I will do that.
and also, thank you! ;)
Comment 14•10 years ago
|
||
(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 :)
Updated•8 years ago
|
Priority: P1 → --
Comment 15•7 years ago
|
||
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Comment 16•7 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•