Closed
Bug 321558
Opened 18 years ago
Closed 18 years ago
document.write not Honoring TITLE
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: BijuMailList, Assigned: mrbkap)
References
Details
(Keywords: fixed1.8.1, verified1.8.0.1, Whiteboard: [patch])
Attachments
(2 files)
3.98 KB,
text/html
|
Details | |
1.39 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
dveditz
:
approval1.8.0.1+
dveditz
:
approval1.8.1+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051219 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051219 Firefox/1.6a1 There are major issues with document.write * It is not Honoring TITLE tag * It is not parsing after SCRIPT, LINK tag with a src attribute, src can be from HTTP, FTP, FILE or DATA This is very major because it will mak problem in many bank sites which use popup. Reproducible: Always Steps to Reproduce: go thru each test in js_doc_write.html test 0 look, title on new window test 2 look, content on new window test 4 look, content on new window Actual Results: test 0 title show url test 2 content empty test 4 content empty Expected Results: test 0 title Hello test 2 should show content test 4 should show content in red
Updated•18 years ago
|
Assignee: general → general
Component: JavaScript Engine → DOM
QA Contact: general → ian
Updated•18 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•18 years ago
|
||
Taking this bug to fix the title problem only. On testcase 0, I see: ###!!! ASSERTION: More UnblockOnload() calls than BlockOnload() calls. I'll file new bugs on the <script> and <link> problems and the assertion.
Assignee: general → mrbkap
Severity: critical → normal
Priority: -- → P3
Summary: document.write not Honoring TITLE and parsing breaks after SCRIPT, LINK → document.write not Honoring TITLE
Target Milestone: --- → mozilla1.9alpha
Assignee | ||
Comment 3•18 years ago
|
||
The problem here is that when we create the new document (from the window.open call) we load about:blank into it, which gives the document a non-void title, so when we parse the <title> from the document.write, we see that the document already has a title, and don't overwrite it.
Attachment #207057 -
Flags: superreview?(bzbarsky)
Attachment #207057 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
Whiteboard: [patch]
![]() |
||
Comment 4•18 years ago
|
||
Comment on attachment 207057 [details] [diff] [review] Void the title We probably want this on 1.8.x, 1.8.0.x, 1.7.x, and Aviary 1.0.x branches... :(
Attachment #207057 -
Flags: superreview?(bzbarsky)
Attachment #207057 -
Flags: superreview+
Attachment #207057 -
Flags: review?(bzbarsky)
Attachment #207057 -
Flags: review+
Assignee | ||
Comment 5•18 years ago
|
||
I filed bug 321782 and bug 321781.
is this same? bug 318401 (no title) also there is unconformed bug 308667 - document.open permission issue
Assignee | ||
Comment 7•18 years ago
|
||
*** Bug 318401 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 8•18 years ago
|
||
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Comment 9•18 years ago
|
||
bz, any reason you didn't nominate? I'll let mrbkap nominate the patch. /be
Flags: blocking1.8.0.1?
Flags: blocking1.7.13?
Flags: blocking-aviary1.0.8?
Assignee | ||
Comment 10•18 years ago
|
||
Comment on attachment 207057 [details] [diff] [review] Void the title This is a safe patch that allows entirely document.written documents to write out <title> tags. If the title is never set, then nsHTMLContentSink::DidBuildModel makes sure to set a non-void title.
Attachment #207057 -
Flags: approval1.8.0.1?
Comment 11•18 years ago
|
||
When did this break? Does it occur in 1.0.6 or 1.0.7?
Assignee | ||
Comment 12•18 years ago
|
||
Actually, 1.0.x isn't affected by this because it used a different (buggy) method of tracking whether the title had been set or not already (see bug 271996).
Assignee | ||
Comment 13•18 years ago
|
||
(In reply to comment #12) > Actually, 1.0.x isn't affected by this because it used a different (buggy) > method of tracking whether the title had been set or not already (see bug > 271996). > So, to be clear, this is a regression from 1.0.x (namely from bug 271996 and bug 304388).
Comment 14•18 years ago
|
||
Comment on attachment 207057 [details] [diff] [review] Void the title a=dveditz for drivers
Attachment #207057 -
Flags: approval1.8.1+
Attachment #207057 -
Flags: approval1.8.0.1?
Attachment #207057 -
Flags: approval1.8.0.1+
Updated•18 years ago
|
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+
Flags: blocking1.7.13?
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8+
Updated•18 years ago
|
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8+
Comment 16•18 years ago
|
||
verified on the branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1. I ran through the set of test cases in https://bugzilla.mozilla.org/attachment.cgi?id=206870 and everything looked good.
Keywords: fixed1.8.0.1 → verified1.8.0.1
Comment 17•18 years ago
|
||
I wanted to note that the JS console did catch an exception when you run the second test case in the example: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.focus]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://browser/content/browser.js :: delayedStartup :: line 779" data: no]
![]() |
||
Updated•17 years ago
|
Flags: in-testsuite?
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•