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,<html><body><img src='resource://jid1-ssgtv6r069pobq-at-jetpack/killit/data/Hand_with_knife24.png'></body></html>"/>
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.
--
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.