Closed Bug 276037 Opened 20 years ago Closed 18 years ago

In application/xhtml+xml during page load getElementsByTagNameNS and getElementsByTagName does not find all currently parsed elements

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: martin.honnen, Unassigned)

References

(
URL
)

Details

Attachments

(3 files)

test case that shows that getElementsByTagNameNS and getElementsByTagName doesn't find all parsed elements during page load
2.93 KB, application/xhtml+xml
Details
workaround as long as bug is not fixed
3.26 KB, application/xhtml+xml
Details
Tests
10.43 KB, patch
Details | Diff | Splinter Review
HTML and XHTML allow the use of the <script> element to embed script code in the document. The script code inside of a <script> element has traditionally been executed during loading of the document, directly after the <script> element has been parsed. For instance in HTML (text/html) documents people use document.write to insert content into the document during page load. With "real" XHTML, meaning with application/xhtml+xml content, document.write is no longer available but of course scripters would still like to insert content into the document with script while the page loads. My solution for that is to use document.getElementsByTagName('script') respectively document.getElementsByTagNameNS('http://www.w3.org/1999/xhtml', 'script') to grab the last <script> element in the document and call appendChild on its parent node, in the hope that while the script code inside of a <script> element is executed that <script> element is already available in the DOM tree and thus any content is executed directly after the <script> element, the same way document.write would do it. However with Mozilla (tested with the latest nightly Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041225 as well as with Firefox 1.0 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0) the approach doesn't work when the <script> element sits inside of a table cell inside of a document served as application/xhtml+xml. The test case at: http://home.arcor.de/martin.honnen/mozillaBugs/domInsertionDuringPageLoad/domInsertionDuringPageLoad.xhtml shows that the <script> element inside of the table cell is not yet found by the getElementsByTagName/getElementsByTagNameNS('script') so that the text meant to be inserted into the table cell ends up as a child of the parent node of an earlier <script> element. The same test case served as text/html, available here: http://home.arcor.de/martin.honnen/mozillaBugs/domInsertionDuringPageLoad/domInsertionDuringPageLoad.html however works as intended, the code inside of a <script> element finds that <script> element in the DOM tree and is able to append to its parent node. While I cannot cite a specification saying that script code run during page load needs to have access to the DOM tree including the <script> element the code is contained in that would be highly desirable in my view as it is the only way for script in application/xhtml+xml to insert content at the position of the <script> element. Therefore I file this bug on Mozilla. I add that this is becoming more important as an increasing number of people are using content type negotiation to serve XHTML as text/html to IE but as application/xhtml+xml to Mozilla (or other browsers understanding XML) and therefore use script in application/xhtml+xml and run into the problem to have the script run during page load insert content into the page when and where the script is executed. One newsgroup post about that topic is here: http://groups-beta.google.com/group/netscape.public.mozilla.dom/browse_frm/thread/a9be9f42491271ad/09ad74e3c8fec90c?tvc=1&scrollSave=&&d#09ad74e3c8fec90c
I think this is because of bug 18333. See also 232004 comment 9.
Depends on: incrementalxml
Martin, is the table cell relevant? That is, if you replace it with a paragraph, do you still see the problem? What about if the <script> is just a child of <body>? Anne, this is rather unlikely to be a consequence of bug 18333 -- that bug is about _layout_ objects not being constructed, and this bug is about the content model and looks like it should be reproducible even in a display:none iframe (where there are no layout objects in sight).
No longer depends on: incrementalxml
I have done some further tests and Boris rightly suspects that the table is not relevant, changing summary to reflect that. In the following application/xhtml+xml test case: http://home.arcor.de/martin.honnen/mozillaBugs/domInsertionDuringPageLoad/domInsertionDuringPageLoadParagraph.xhtml there are only paragraphs but only the script code in the first <script> element inserts content into its parent node while all following scripts insert content as a child of the first paragraph which is the parent node of the first <script> element. The same test case as text/html works fine: http://home.arcor.de/martin.honnen/mozillaBugs/domInsertionDuringPageLoad/domInsertionDuringPageLoadParagraph.html
Summary: In application/xhtml+xml a script element inside a table cell is not yet available in the DOM when the script executes → In application/xhtml+xml a script element is not yet available in the DOM when the script executes
Further investigation shows that the problem is that during page load in application/xhtml+xml content the methods document.getElementsByTagName and document.getElementsByTagNameNS do not find all parsed elements. The test case during page load counts XHTML span and script elements using the two methods and manually walking the document tree, while the tree walks shows that the last span and script element has been parsed and is in the document tree the two methods do not find those elements, only after onload the methods find the correct number of elements.
Changing summary again to reflect the findings of the last test case <https://bugzilla.mozilla.org/attachment.cgi?id=169634> which shows that the problem is not restricted to <script> elements not being found but other elements like <span> too.
Summary: In application/xhtml+xml a script element is not yet available in the DOM when the script executes → In application/xhtml+xml during page load getElementsByTagNameNS and getElementsByTagName does not find all currently parsed elements
Hmm... It'd be interesting to see exactly what the callstack looks like when we actually do anything in nsHTMLScriptElement::MaybeProcessScript, i.e. when we reach line 649 in that file. I would exect things to work since we in nsGenericElement::AppendChildTo add the new child to mAttrsAndChildren before we call SetDocument on it.
The problem is that content lists are lazy and rely on the ContentAppended/ContentInserted/ContentRemoved notifications to clear their cached state. But the XML content sink doesn't fire these notifications until the parsing is finished and it fires a single ContentInserted on the root.... Perhaps content lists should be non-lazy for still-loading xml documents (as a short-term hack or something)? What should the behavior of content lists be when they're created by a script element in a document that is then transformed with xslt, btw?
Shouldn't "we" "just" make the XML content sink fire the notifications like the HTML content sink?
I'm not sure, in part because I'm not sure how that interacts with XSLT. When we transform, do we change document objects too, or just stick the transformation result into the original document? If the latter, content lists created in the pre-transform document would start seeing post-transform content, which is undesirable. For the rest, I think it should be safe to do content notifications, since we wouldn't call InitialReflow, so frame construction would be suppressed. But we may still up with significant inefficiency from once-per-content notification, whereas a batching system like the HTML sink would take some work (see bug 18333).
ccing people who may know answers to my questions...
XSLT creates a compleatly new document (so that we can create an html document rather then an xml one). Also, it shouldn't be an issue with stuff created in the original document, since we shouldn't be running any scripts at all in that document once we detect that we're going to XSLT transform it (not sure if we actually do that currently). XSLT currently use DOM methods to create the result tree, so I would think that we send out notifications continously. This might change though if we switch over to the faster nsIContent interfaces.
I attach this as workaround as long as the bug is not fixed as the problem of inserting content during page load into application/xhtml+xml comes up again and again in newsgroups. Instead of using getElementsByTagName(NS) to find the last and current <script> element the workaround looks at the childNodes and that way is able to find the correct <script> element.
Just as an additional information: I've tripped on this problem in one of my projects too, where a script basically needs to located its own script element in order to be able to "include" more script files automatically. This currently fails, because getElementByTagName() does not return all script DOM nodes. However, when looking at document and its child DOM elements, I can find the "missing" DOM node.
Fixed by bug 18333. (I was able to reproduce the bug using an opt build from a few days ago, but not using a debug build with the fix for bug 18333.)
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
PLEASE mark the in-testsuite stuff when resolving. Or better yet, add the tests!
Flags: in-testsuite?
OK. So I wrote a regression test for this based on attachment 169634 [details]. Sometimes the test succeeds. Sometimes it fails. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
could be a regression from 18333
No, it was broken before 18333.
Depends on: 369011
Attached patch Tests — — Splinter Review
The random failures are due to bug 369011 (yay writing regression tests!). Once that lands I'll land these tests.
Tests committed. Now they pass.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Component: DOM: Core → DOM: Core & HTML
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: