Using openDialog()

387 views
Skip to first unread message

Anthony Shipman

unread,
Apr 5, 2014, 1:39:57 AM4/5/14
to mozilla-la...@googlegroups.com
When I call window/utils openDialog() to create a real dialog
I find that the resulting window doesn't receive a 'load' event
unless the URL is for chrome. In the simplest case I can write

const dlgMainURL = data.url("dlgMain.html");

let old = winutils.getMostRecentBrowserWindow();
let win = old.openDialog(dlgMainURL, "main", "dialog=yes,modal=no");
//let win = old.openDialog("chrome://browser/content/aboutDialog.xul",
"main", "dialog=yes,modal=no");

win.addEventListener("load", function()
{
log("*** window loaded");
...
}

The event is not delivered. If I change the URL to the aboutDialog.xul
the event is delivered. Is this a bug in Firefox or are there some extra
steps I should be taking?

--
Anthony Shipman Mamas don't let your babies
a...@iinet.net.au grow up to be outsourced.

ZER0

unread,
Apr 5, 2014, 3:41:27 PM4/5/14
to mozilla-la...@googlegroups.com
On 05/04/14 07:39 , Anthony Shipman wrote:
> When I call window/utils openDialog() to create a real dialog
> I find that the resulting window doesn't receive a 'load' event
> unless the URL is for chrome.

It's normal. It's just a wrapper to low level method, that is intended
to be XUL only. If you want to open an HTML Document, you actually need
to open a dialog with the browser interface
(chrome://browser/content/browser.xul), and then you can load the HTML
page you want to, and get the relative events.

It becomes more complicate if you want to also to dialog with such
document using the SDK messages API. So far, we're not going to
implement any methods in the SDK to do so (see
https://bugzilla.mozilla.org/show_bug.cgi?id=907437 for further
details), but in the meantime I wrote a small 3rd party module to make
it a bit easier:

https://github.com/ZER0/dialog

Hope it helps!


Anthony Shipman

unread,
Apr 5, 2014, 4:42:25 PM4/5/14
to mozilla-la...@googlegroups.com
On Sun, 6 Apr 2014 05:41:27 am ZER0 wrote:
> On 05/04/14 07:39 , Anthony Shipman wrote:
> > When I call window/utils openDialog() to create a real dialog
> > I find that the resulting window doesn't receive a 'load' event
> > unless the URL is for chrome.
>
> It's normal. It's just a wrapper to low level method, that is intended
> to be XUL only. If you want to open an HTML Document, you actually need
> to open a dialog with the browser interface
> (chrome://browser/content/browser.xul), and then you can load the HTML
> page you want to, and get the relative events.

The main problem I have with having a real browser is that the window title is
spoiled. The scheme and host part of the resource: URL is put into the title.
tabbrowser.xml has

// If location bar is hidden and the URL type supports a host,
// add the scheme and host to the title to prevent spoofing.
// XXX https://bugzilla.mozilla.org/show_bug.cgi?id=22183#c239

I want to avoid this. I'll try loading a XUL document and then put my HTML
document into an IFRAME within it.

>
> It becomes more complicate if you want to also to dialog with such
> document using the SDK messages API. So far, we're not going to
> implement any methods in the SDK to do so (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=907437 for further
> details), but in the meantime I wrote a small 3rd party module to make
> it a bit easier:
>
> https://github.com/ZER0/dialog
>
> Hope it helps!
>

Thanks. I've already looked at that. It doesn't appear to be necessary.
If I open a real browser window with window.open or window.openDialog then
page-mod will correctly attach a worker.

ZER0

unread,
Apr 6, 2014, 5:40:03 AM4/6/14
to mozilla-la...@googlegroups.com
On 05/04/14 22:42 , Anthony Shipman wrote:

> The main problem I have with having a real browser is that the window title is
> spoiled. The scheme and host part of the resource: URL is put into the title.
> tabbrowser.xml has
>
> // If location bar is hidden and the URL type supports a host,
> // add the scheme and host to the title to prevent spoofing.
> // XXX https://bugzilla.mozilla.org/show_bug.cgi?id=22183#c239
>
> I want to avoid this. I'll try loading a XUL document and then put my HTML
> document into an IFRAME within it.

You can simple change the title. I had the same issue in my `dialog`
module; you can use the same approach I had, change the title once the
document is loaded:

<https://github.com/ZER0/dialog/blob/master/lib/dialog.js#L73>

> Thanks. I've already looked at that. It doesn't appear to be necessary.
> If I open a real browser window with window.open or window.openDialog then
> page-mod will correctly attach a worker.

Sure, but that takes care of the all "chaining" opening events too, plus
it doesn't rely on other high level API such Page-Mod. You can always
use the module above without passing any `contentScript*` and then use
Page-Mod; or either grab the code in the module that you need.

The snipped that was the prototype of this module shows you how to open
a HTML Document without content script:

https://gist.github.com/ZER0/9746736

You just need to add the "load" event to the `window` returned by the
promise, in your case.

Anthony Shipman

unread,
Apr 6, 2014, 6:22:55 PM4/6/14
to mozilla-la...@googlegroups.com
On Sun, 6 Apr 2014 07:40:03 pm ZER0 wrote:
> The snipped that was the prototype of this module shows you how to open
> a HTML Document without content script:
>
> https://gist.github.com/ZER0/9746736
>
> You just need to add the "load" event to the `window` returned by the
> promise, in your case.
>
I've experimented with the following code from your gist. The SDK is 1.16
and FF is 27 or 28.

require("sdk/window/helpers").open("", {
features: {
toolbar: false,
location: false,
resizable: true,
scrollbars: true,
width: 700,
height: 600
}
}).then(window => {
console.log("open then");
let tab = tu.getActiveTab(window);
tu.setTabURL(tab, dlgMainURL);
window.setTimeout(() => tu.setTabTitle(tab, "Title"), 1000);
});

If both the toolbar and location are omitted then I get this error upon
opening the dialog:
TypeError: frame.contentDocument is undefined

with partial stack trace:
deprecated/symbiont.js:151
sdk/widget.js:539
deprecated/window-utils.js:131
Other cascade errors follow later.

Still, the dialog opens and a script is attached (via page-mod) and runs but
the title bar includes the URL. Enabling the location feature makes this go
away. There is nothing I can see in the code of tabbrowser.xml to indicate it
could be any other way. The setTabTitle call only changes the label on the
tab.

Setting a parent in the open() call with an empty URL will load the browser
early and the frame.contentDocument error disappears. The window title
includes "chrome://browser" and I can't get rid of the menubar and location
features. There is no load event. Setting the chrome feature brings back
the frame.contentDocument error but the dialog works.

Setting a URL in the open() call, without a parent, loads it as chrome and
there is no load event. The dialog window title exactly follows the <title> in
the loaded page.

ZER0

unread,
Apr 7, 2014, 6:19:05 AM4/7/14
to mozilla-la...@googlegroups.com
On 07/04/14, 24:22 , Anthony Shipman wrote:

>> The snipped that was the prototype of this module shows you how to open
>> a HTML Document without content script:
>>
>> https://gist.github.com/ZER0/9746736
>>
>> You just need to add the "load" event to the `window` returned by the
>> promise, in your case.

> I've experimented with the following code from your gist. The SDK is 1.16
> and FF is 27 or 28.

Can you try with the latest Nightly, using the -o option from `cfx`? I
didn't have such issue, so I'm trying to isolate the differences and see
why that is happening.
>
> require("sdk/window/helpers").open("", {
> features: {
> toolbar: false,
> location: false,
> resizable: true,
> scrollbars: true,
> width: 700,
> height: 600
> }
> }).then(window => {
> console.log("open then");
> let tab = tu.getActiveTab(window);
> tu.setTabURL(tab, dlgMainURL);
> window.setTimeout(() => tu.setTabTitle(tab, "Title"), 1000);

I would say, it's better if you're waiting that the document in the tab
is ready without rely on the timeout.

> });

Did you try the gist as is, without any additional code? Did is raise
the same exception?

> If both the toolbar and location are omitted then I get this error upon
> opening the dialog:
> TypeError: frame.contentDocument is undefined
>
> with partial stack trace:
> deprecated/symbiont.js:151
> sdk/widget.js:539
> deprecated/window-utils.js:131
> Other cascade errors follow later.

This is weird, I don't think is related at all. The code doesn't have
any widget, neither it using deprecated APIs. I assume you have widgets
around your code?

> Still, the dialog opens and a script is attached (via page-mod) and runs but
> the title bar includes the URL.

Did you try the module I linked in the previous post? Do you have the
same issue? (title is not changed, exception is raised)

Anthony Shipman

unread,
Apr 7, 2014, 3:57:50 PM4/7/14
to mozilla-la...@googlegroups.com

On Mon, 7 Apr 2014 08:19:05 pm ZER0 wrote:

> >

> > I've experimented with the following code from your gist. The SDK is 1.16

> > and FF is 27 or 28.

>

> Can you try with the latest Nightly, using the -o option from `cfx`? I

> didn't have such issue, so I'm trying to isolate the differences and see

> why that is happening.

It also happens with firefox-31.0a1 which is a recent nightly.

>

> > require("sdk/window/helpers").open("", {

> > features: {

> > toolbar: false,

> > location: false,

> > resizable: true,

> > scrollbars: true,

> > width: 700,

> > height: 600

> > }

> > }).then(window => {

> > console.log("open then");

> > let tab = tu.getActiveTab(window);

> > tu.setTabURL(tab, dlgMainURL);

> > window.setTimeout(() => tu.setTabTitle(tab, "Title"), 1000);

>

> I would say, it's better if you're waiting that the document in the tab

> is ready without rely on the timeout.

That was just an experiment to see the effect of the function.

> > });

>

> Did you try the gist as is, without any additional code? Did is raise

> the same exception?

The only extra code is the console.log.

>

> > If both the toolbar and location are omitted then I get this error upon

> > opening the dialog:

> > TypeError: frame.contentDocument is undefined

> >

> > with partial stack trace:

> > deprecated/symbiont.js:151

> > sdk/widget.js:539

> > deprecated/window-utils.js:131

> > Other cascade errors follow later.

>

> This is weird, I don't think is related at all. The code doesn't have

> any widget, neither it using deprecated APIs. I assume you have widgets

> around your code?

deprecated/window-utils has a nsIWindowWatcher which responds to the new dialog window appearing. The browserManager in widget.js uses it to track all new windows to see if it should add a widget to a toolbar on them. Something goes wrong during the construction of the symbiont for the widget after setting the src for the iframe in the XUL toolbaritem element.

With firefox-31.0a1

With chrome=true and a parent browser:

DOM inspector shows that the iframe is XUL and has no contentDocument attribute. This happens when I set chrome: true in the features. The outerHTML is:

<iframe xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" type="content" transparent="transparent" style="overflow: hidden; height: 16px; max-height: 16px; width: 16px; border: medium none; padding: 0px;" flex="1" src="data:text/html;charset=utf-8,&lt;html&gt;&lt;body&gt;&lt;img src='resource://jid1-ssgtv6r069pobq-at-jetpack/killit/data/Hand_with_knife24.png'&gt;&lt;/body&gt;&lt;/html&gt;"/>

The iframe on the main window that contains my widget does have a contentDocument attribute and a contentWindow and a docShell. It looks like chrome=true suppresses the docShell.

Perhaps this could be a bug report. The SDK widget should be more careful to not try to attach to chrome windows.

With chrome=false and a parent browser:

There is no iframe. The widget has been skipped. The isBrowser() test in

widget fails because the dialog window's document hasn't been initialised at that time. It is still 'about:blank'

It appears that the only time I don't get this frame.contentDocument error is when nothing is loaded into the dialog, because there has been no load event from the call to open(). This happens when the URL is empty and there is a parent browser and the features have chrome=false.

>

> > Still, the dialog opens and a script is attached (via page-mod) and runs

> > but the title bar includes the URL.

>

> Did you try the module I linked in the previous post? Do you have the

> same issue? (title is not changed, exception is raised)

>

Using your dialog.js code produces exactly the same result.

ZER0

unread,
Apr 8, 2014, 3:12:06 AM4/8/14
to mozilla-la...@googlegroups.com
On 07/04/14, 21:57 , Anthony Shipman wrote:

>> Can you try with the latest Nightly, using the -o option from `cfx`? I
>> didn't have such issue, so I'm trying to isolate the differences and see
>> why that is happening.

> It also happens with firefox-31.0a1 which is a recent nightly.

[..]

>> Did you try the gist as is, without any additional code? Did is raise
>> the same exception?

> The only extra code is the console.log.

Well, no, you have also the tab title and everything. I was just wanted
isolate the issue 'cause with just executing the code in the gist as is
I do not have the exception you're mentioning; so if also it happening
in the Nightly you must have some other code around I guess, otherwise I
can't explain the difference.

>> > with partial stack trace:
>> > deprecated/symbiont.js:151
>> > sdk/widget.js:539
>> > deprecated/window-utils.js:131
>> > Other cascade errors follow later.

>> This is weird, I don't think is related at all. The code doesn't have
>> any widget, neither it using deprecated APIs. I assume you have widgets
>> around your code?

> deprecated/window-utils has a nsIWindowWatcher which responds to the new
> dialog window appearing.
The browserManager in widget.js uses it to
> track all new windows to see if it should add a widget to a toolbar on
> them.

Yes, but if you do not require `widget` module then you shouldn't have
such code in memory. So do you have other code that you're executing
beside the one posted here? Do you have widgets in your code? If yes,
could you publish the minimum test case of your code so I can reproduce
the issue? Just to be sure we're on the same page.

> Something goes wrong during the construction of the symbiont for
> the widget after setting the src for the iframe in the XUL toolbaritem
> element.

Probably. BTW with Australis – Firefox 29 – Widgets are deprecated, and
we suggests to the developers to use new UI Components instead.
If you're using a widget in your code, probably switching to the new
button API will make the exception disappears.

> With firefox-31.0a1
>
> With chrome=true and a parent browser:
>
> DOM inspector shows that the iframe is XUL and has no contentDocument
> attribute. This happens when I set chrome: true in the features. The
> outerHTML is:

So, if you do not set chrome true everything works?

If you could provide a simple main.js somewhere with the test case it
would be helpful.

> Perhaps this could be a bug report. The SDK widget should be more
> careful to not try to attach to chrome windows.

Well, it's attach to anything it is a browser window, and loading
browser.xul makes it a browser window I guess.
But again, I'm presuming things, it would be much better if I can
reproduce the issue with the same code of yours.

> It appears that the only time I don't get this frame.contentDocument
> error is when nothing is loaded into the dialog, because there has been
> no load event from the call to open(). This happens when the URL is
> empty and there is a parent browser and the features have chrome=false.

>> Did you try the module I linked in the previous post? Do you have the
>> same issue? (title is not changed, exception is raised)

> Using your dialog.js code produces exactly the same result.

Interesting, I presume then is definitely the interaction with the
widgets to produce such result, just wondering why this is happening
only when the title is changed, even in two different ways. Please, if
you could provide the code I will take a look, and depends by type of
bug we could try to provide a fix to widgets too, even if it's deprecated.

ZER0

unread,
Apr 8, 2014, 4:21:55 AM4/8/14
to mozilla-la...@googlegroups.com
On 08/04/14, 09:12 , ZER0 wrote:

>>> This is weird, I don't think is related at all. The code doesn't have
>>> any widget, neither it using deprecated APIs. I assume you have widgets
>>> around your code?
>
>> deprecated/window-utils has a nsIWindowWatcher which responds to the new
>> dialog window appearing.
> The browserManager in widget.js uses it to
>> track all new windows to see if it should add a widget to a toolbar on
>> them.
>
> Yes, but if you do not require `widget` module then you shouldn't have
> such code in memory. So do you have other code that you're executing
> beside the one posted here? Do you have widgets in your code? If yes,
> could you publish the minimum test case of your code so I can reproduce
> the issue? Just to be sure we're on the same page.

Okay, I think this is more or less the code you probably have:

const url = 'data:text/html;charset=utf-8,<html>Hello</html>';
const { getActiveTab, setTabURL } = require('sdk/tabs/utils');
const { open } = require("sdk/window/helpers");

require('sdk/widget').Widget({
content: 'hi',
label: 'hi',
id: 'hi',
onClick: openDialog
});

function openDialog() {
open("", {
features: {
toolbar: false,
location: false,
resizable: true,
scrollbars: true,
width: 700,
height: 600
}
}).then(window => {
let tab = getActiveTab(window);
setTabURL(tab, url);
}).then(null, console.error);
}

I got confused about the discussion related to the title and it wasn't
makes sense to me.

So, as said previously using the new UI buttons instead of widget will
definitely remove the exceptions, however it's worthy to file a bug
about it.

I can do that if you prefer.

Anthony Shipman

unread,
Apr 8, 2014, 10:45:15 AM4/8/14
to mozilla-la...@googlegroups.com
On Tue, 8 Apr 2014 06:21:55 pm ZER0 wrote:
> On 08/04/14, 09:12 , ZER0 wrote:
> >>> This is weird, I don't think is related at all. The code doesn't have
> >>> any widget, neither it using deprecated APIs. I assume you have widgets
> >>> around your code?

This is part of a whole add-on so there is more code elsewhere.

> Okay, I think this is more or less the code you probably have:
>
> const url = 'data:text/html;charset=utf-8,<html>Hello</html>';
> const { getActiveTab, setTabURL } = require('sdk/tabs/utils');
> const { open } = require("sdk/window/helpers");
>
> require('sdk/widget').Widget({
> content: 'hi',
> label: 'hi',
> id: 'hi',
> onClick: openDialog
> });
>
> function openDialog() {
> open("", {
> features: {
> toolbar: false,
> location: false,
> resizable: true,
> scrollbars: true,
> width: 700,
> height: 600
> }
> }).then(window => {
> let tab = getActiveTab(window);
> setTabURL(tab, url);
> }).then(null, console.error);
> }

That reproduces the error. You will also see the ¨data:¨ in the title bar of
the dialog which is the problem I started with. It looks a lot worse when it
says ¨resource://jid1-ssgtv6r069pobq-at-jetpack¨

>
> So, as said previously using the new UI buttons instead of widget will
> definitely remove the exceptions, however it's worthy to file a bug
> about it.
>
> I can do that if you prefer.
Thanks

Adrian Aichner

unread,
Apr 8, 2014, 11:12:52 AM4/8/14
to mozilla-la...@googlegroups.com
Anthony, can you post the exception text you are getting on setting the title?

Are you sure the document is fully loaded at that point in time?

The locationbar will always the the URL, but the title should be changeable.



--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mozilla-labs-jet...@googlegroups.com.
To post to this group, send email to mozilla-la...@googlegroups.com.
Visit this group at http://groups.google.com/group/mozilla-labs-jetpack.
For more options, visit https://groups.google.com/d/optout.

Anthony Shipman

unread,
Apr 11, 2014, 1:03:03 AM4/11/14
to mozilla-la...@googlegroups.com
On Wed, 9 Apr 2014 01:12:52 am Adrian Aichner wrote:
> Anthony, can you post the exception text you are getting on setting the
> title?
>
> Are you sure the document is fully loaded at that point in time?
>
> The locationbar will always the the URL, but the title should be
> changeable.
>
I don't get an exception when setting the title. What I want to avoid is part
of the URL appearing in the title bar, which it will when I omit the location
bar from the window. So I'm having to use a XUL container to hold the dialog.

ZER0

unread,
Apr 11, 2014, 1:47:15 AM4/11/14
to mozilla-la...@googlegroups.com
On 08/04/14 16:45 , Anthony Shipman wrote:
>> Okay, I think this is more or less the code you probably have:
[..]
> That reproduces the error. You will also see the ¨data:¨ in the title bar of
> the dialog which is the problem I started with.

Yeah, but I already told you how to fix that, no? You can just set the
title once the document is loaded.

>> So, as said previously using the new UI buttons instead of widget will
>> definitely remove the exceptions, however it's worthy to file a bug
>> about it.

>> I can do that if you prefer.

Here: https://bugzilla.mozilla.org/show_bug.cgi?id=995080

As I said, not sure it would be fixed, because widgets are deprecated
and with the new button there is no such issue, but you can following
the bug if you're interested.

I would suggest to you anyway to use the new UI API, unless you've
particular reason to not do so.

> Thanks

Thanks to you for noticing the bug!

Anthony Shipman

unread,
Apr 11, 2014, 3:16:01 PM4/11/14
to mozilla-la...@googlegroups.com
On Fri, 11 Apr 2014 03:47:15 pm ZER0 wrote:
> Yeah, but I already told you how to fix that, no? You can just set the
> title once the document is loaded.

This brings me back to the original problem. Using your example code:

const url = 'data:text/html;charset=utf-8,<html><head><title>Page
Title</title></head>Hello</html>';
....
}).then(window => {
let tab = getActiveTab(window);
setTabURL(tab, url);
}

further experimentation just now shows that I don't get a load, ready or
pageshow event for the tab. Nor do I get a load or ready event for the window.
I do however get a pageshow event for the window which allows me to set the
title with
window.document.title = "Testing";
so that may be good enough. The code in tabbrowser.xml and
nsContentTreeOwner::SetTitle() makes me wonder if it will be reliable though.

>
> I would suggest to you anyway to use the new UI API, unless you've
> particular reason to not do so.

Because the documentation says it is not available until FF 29 which is not
out yet. Any add-on I write must continue to work with older versions of FF
until everyone has migrated.

ZER0

unread,
Apr 12, 2014, 5:31:37 AM4/12/14
to mozilla-la...@googlegroups.com
On 11/04/14 21:16 , Anthony Shipman wrote:
> On Fri, 11 Apr 2014 03:47:15 pm ZER0 wrote:

>> Yeah, but I already told you how to fix that, no? You can just set the
>> title once the document is loaded.

> This brings me back to the original problem. Using your example code:

> const url = 'data:text/html;charset=utf-8,<html><head><title>Page
> Title</title></head>Hello</html>';
> ....
> }).then(window => {
> let tab = getActiveTab(window);
> setTabURL(tab, url);
> }

> further experimentation just now shows that I don't get a load, ready or
> pageshow event for the tab.
> Nor do I get a load or ready event for the window.

ready ('DOMContentLoaded') works for me:

const url = 'data:text/html;charset=utf-8,<html>Hello</html>';
const { getActiveTab, setTabURL } = require('sdk/tabs/utils');
const { open, ready } = require("sdk/window/helpers");

open("", {
features: {
toolbar: false,
location: false,
resizable: true,
scrollbars: true,
width: 700,
height: 600
}
}).then(window => {
window.addEventListener('DOMContentLoaded', () => {
window.document.title = 'foo';
});

let tab = getActiveTab(window);
setTabURL(tab, url);
}).then(null, console.error);

>> I would suggest to you anyway to use the new UI API, unless you've
>> particular reason to not do so.

> Because the documentation says it is not available until FF 29 which is not
> out yet.
> Any add-on I write must continue to work with older versions of FF
> until everyone has migrated.

It will be soon, and widgets will be deprecated with that. Widgets
wouldn't provide also a good UX experience in Australis unfortunately,
so it's strongly suggested to migrate the code. You can always use both
in SDK 1.16; so you can use the widgets for your users with FF < 29 and
the new UI API for Australis; that would be much better than use widgets
in Austrailis.

Anthony Shipman

unread,
Apr 13, 2014, 1:17:26 AM4/13/14
to mozilla-la...@googlegroups.com
On Sat, 12 Apr 2014 07:31:37 pm ZER0 wrote:
> > further experimentation just now shows that I don't get a load, ready or
> > pageshow event for the tab.
> > Nor do I get a load or ready event for the window.
>
> ready ('DOMContentLoaded') works for me:
>

How is that I can get DOMContentLoaded but not load?

ZER0

unread,
Apr 13, 2014, 2:48:54 AM4/13/14
to mozilla-la...@googlegroups.com
On 13/04/14 07:17 , Anthony Shipman wrote:

> On Sat, 12 Apr 2014 07:31:37 pm ZER0 wrote:
>>> further experimentation just now shows that I don't get a load, ready or
>>> pageshow event for the tab.
>>> Nor do I get a load or ready event for the window.
>>
>> ready ('DOMContentLoaded') works for me:

> How is that I can get DOMContentLoaded but not load?

So, is it works for you too? Because you said that you didn't get the
ready event. Have you done something different?

You can get the `DOMContentLoaded` but not the `load` because the first
is bubbling and second is not.
You do not attach the listener directly to the window you want to, but
to the browser window.
So basically when the (content) window, that is a child of the browser
window fires the `DOMContentLoaded`, this event is bubbling up to the
browser window, where you have the listener, and therefore you receive
it, where is not for the `load` event.

See:

<https://developer.mozilla.org/en-US/docs/Web/Reference/Events/load>
<https://developer.mozilla.org/en-US/docs/Web/Reference/Events/DOMContentLoaded>

In your case `DOMContentLoaded` is anyway the event you need, because
you want to set the title as soon as the document is ready, you don't
want to wait for any resource to be loaded, otherwise the user could
have the "ugly" title displayed for longer.
However, if you need to wait for the load event for any other reason
(e.g. the document you're displaying loads a heavy image or resource,
and you want to display a loading stuff, and hiding when it's done), you
can simple attach it to the right window object, once you have it:

// just show the part we're talking
}).then(window => {
window.addEventListener('DOMContentLoaded', ({target}) => {
window.document.title = 'foo'; // or target.title

target.defaultView.addEventListener('load', () =>
console.log('do somestuff')
);

Anthony Shipman

unread,
Apr 13, 2014, 4:48:11 AM4/13/14
to mozilla-la...@googlegroups.com
On Sun, 13 Apr 2014 04:48:54 pm ZER0 wrote:
> So, is it works for you too? Because you said that you didn't get the
> ready event. Have you done something different?
>
By ready I meant 'ready' as in the event described in the tabs SDK module.
I've tried many combinations of events and targets but I managed to miss
DOMContentLoaded on the browser window.

Thanks for your help.
Reply all
Reply to author
Forward
0 new messages