mozilla.dev.platform Google Group

Re: DOMContentLoaded

bzbar...@mit.edu (Boris Zbarsky) — Mon, 04 Jan 2010 05:27:49 UT

No, that wouldn't work. These would:
<script src="some-cgi-script-that-slee ps-for-more-than-400ms">
(or equivalent with httpd.js).
<script>
var start = new Date;
var end = new Date;
while (end - start < 400) {
end = new Date;
}
</script>
(Of course with the latter there's no guarantee that you'll get back to

Re: DOMContentLoaded

johnjbar...@johnjbarton.com (John J. Barton) — Mon, 04 Jan 2010 05:28:29 UT

Ok good, I think we have sorted this out in Firebug, but we need a test
case we can rely on. How can we ensure that DOMContentLoaded is fired no
sooner than 400ms in a simple page? Load a script from an non-existent
server?
jjb

Re: nsIWebBrowserFind.findNext fails because there is no primary shell for the document

bzbar...@mit.edu (Boris Zbarsky) — Sun, 03 Jan 2010 21:09:54 UT

OK. That's not an unexpected state of being for a document which is not
being shown (for example, which is loaded in a display:none iframe or
the like).
Do you have reason to believe there should in fact be a presshell here?
-Boris

Re: onLocationChange to wyciwyg

bzbar...@mit.edu (Boris Zbarsky) — Sun, 03 Jan 2010 21:08:40 UT

OK....
Fails what where with what JS error?
Just like it was before the reload, right?
That's correct.
No. wyciwyg is an internal URI scheme used to represent document.write
result pages; the location bar shows the thing after the slash which
comes after the number which comes after wyciwig://.
See also nsIURIFixup.createExposableURI .

nsIWebBrowserFind.findNext fails because there is no primary shell for the document

om.brahm...@gmail.com (brahmana) — Sun, 03 Jan 2010 19:50:01 UT

Hi,
I am using nsIWebBrowserFind.findNext (from JS) and it always fails
with NS_ERROR_INVALID_POINTER. Here is the code snippet that I am
working with:
// this.browser is the <browser> associated with a tab, got by
gBrowser.getBrowserAtIndex(i)
var browserFind = this.browser.docShell.getInter face
(Ci.nsIWebBrowserFind);

onLocationChange to wyciwyg

johnjbar...@johnjbarton.com (John J. Barton) — Sun, 03 Jan 2010 18:07:51 UT

While investigating Firebug issue 2649,
[link],
I came up with a weird effect. After I completed the user's test
procedure, I tried to reload the page to start over, but I could not
succeed. The reload request causes an onLocationChange to a url,
wyciwyg://1/[link]

Re: DOMContentLoaded

bzbar...@mit.edu (Boris Zbarsky) — Wed, 30 Dec 2009 18:29:47 UT

What other ways? innerHTML parses into a new document (or more
precisely document fragment), then inserts the nodes into your original
document via a DOM insertNode call. That call triggers mutation events
as needed. The HTML5 spec makes this pretty explicit.
-Boris

Re: DOMContentLoaded

johnjbar...@johnjbarton.com (John J. Barton) — Wed, 30 Dec 2009 18:30:49 UT

So what about setting element.innerHTML and all other ways that look
like parsing is going on?
jjb

Re: DOMContentLoaded

bzbar...@mit.edu (Boris Zbarsky) — Wed, 30 Dec 2009 18:07:50 UT

Yes.
"Do not", rather than "may not". They never trigger mutation events.
DOMContentLoaded just tells you that there will be no more parser
mutations for that document after that point (modulo document.open, of
course).
-Boris

Re: DOMContentLoaded

johnjbar...@johnjbarton.com (John J. Barton) — Wed, 30 Dec 2009 17:56:43 UT

I was confused by the "can't have such an expectation" followed by "of
course". I guess you mean:
Scripted mutations to the document trigger mutation events at all times.
Parser mutations may not trigger mutations events before DOMContentLoaded.
jjb

Re: DOMContentLoaded

bzbar...@mit.edu (Boris Zbarsky) — Wed, 30 Dec 2009 17:06:02 UT

That's not quite right. DOMNodeInserted is not fired for nodes inserted
by the parser. DOMContentLoaded fires at the point when the parser is
done with the document. So after DOMContentLoaded, you can expect to
see mutation events for all mutations to the document; before that you
can't have such an expectation.

Re: Conversion to external linkage

ka...@kairo.at (Robert Kaiser) — Wed, 30 Dec 2009 15:12:00 UT

Neil wrote:
Hmm, I'm not too good at the details of those linkage things when it
comes down to how code is written.
From a build perspective, I'd favor going to libxul or even XULRunner
in the long term, matching what Firefox does as much as possible. I
guess mail would need to be built in the same way as Firefox does with

Re: Page-load performance problem in Gtk (and headless) backend

ch...@linux.intel.com (Chris Lord) — Wed, 30 Dec 2009 14:20:49 UT

Sorry for delay on reply, am on holiday - the bug/patch have indeed been
filed: [link]
--Chris

DOMContentLoaded

johnjbar...@johnjbarton.com (John J. Barton) — Wed, 30 Dec 2009 05:38:23 UT

The documention for DOMContentLoaded makes it sound quite insignificant:
---
Fired on a Window object when a document's DOM content is finished
loading, but unlike "load", does not wait until all images are loaded.
---
Generally Firebug tries to get in to the page as early as possible.
Based on the above, DOMContentLoaded does trigger some Firebug actions,

Re: Conversion to external linkage

benja...@smedbergs.us (Benjamin Smedberg) — Tue, 29 Dec 2009 22:14:37 UT

It is currently true that you should not mix the internal and external
string APIs, because there are symbols shared between them such as
nsString::nsString. That could be fixed by using namespaces, e.g.
mozilla::internal::nsAString / mozilla::glue::nsAString, and the headers
would choose which version to use with `using` declarations and typedefs.