Closed
Bug 22850
Opened 25 years ago
Closed 25 years ago
Anchors created by document.write don't work.
Categories
(Core :: DOM: HTML Parser, defect, P3)
Core
DOM: HTML Parser
Tracking
()
M15
People
(Reporter: sc110, Assigned: eric)
References
()
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
Anchors created by document.write don't work. i.e. ... document.write("<a href='#blah'>go to blah</a>"); ... document.write("<a name='blah'></a>blah"); Doesn't work. It gives a directory listing instead. Using BASE doesn't help either. There is a partial workaround, replacing <a href='#blah'> with <a href='javascript:location.hash=\"blah\"'> does the trick provided the document.write does not occur in an onload handler (i.e. the original document is not completely rewritten). Strange thing is, document.write("<script>alert('The first anchor is ' + document.anchor [0].name);<\/script>"); does show the anchor even in an onload. See URL for full example.
Updated•25 years ago
|
Assignee: mccabe → nisheeth
Component: Javascript Engine → Parser
Comment 1•25 years ago
|
||
Guessing HTML parsing. Nisheeth, can you categorize better?
Updated•25 years ago
|
Assignee: nisheeth → evaughan
Comment 2•25 years ago
|
||
1) nsWebShell::DoLoadURL recognizes the named anchor click properly and calls nsPresShell::GotoAnchor(). 2) nsPresShell::GotoAnchor() looks up frame associated with the HTML element targeted by the named anchor. It passes the frame as an argument to nsPresShell::ScrollFrameIntoView(). 3) nsPresShell::ScrollFrameIntoView() calculates the x,y coordinates that the root scrollable view (nsScrollPortView) needs to jump to (on my box the coordinates were 0, 7995 which seemed reasonable). It passes those coordinates as arguments to nsScrollPortView::ScrollTo(). 4) nsScrollPortView::ScrollTo() converts twips (0, 7995) to pixels (0, 4050) and gets the scrolled view. It calls the SetPosition method on the scrolled view and passes it the pixel coordinates. *** nsView::SetPosition() ends up doing nothing because the view's mWidget member variable is null***. Maybe this is the cause of the bug. nsScrollPortView::ScrollTo() also calculates the difference between the old and new x,y values. It calls nsScrollPortView::Scroll() with the scrolled view and the x, y differences (0, -270) as arguments. This is something else that I don't understand. Should y be a positive value if the named anchor that we are jumping to is "ahead" of the current document position? I am re-assigning this to Eric Vaughan, scroll guru, for further analysis.
Reporter | ||
Comment 3•25 years ago
|
||
FYI, I've found that provided the anchors are not document.written in an event handler like onload, the anchors do work if done in this manner: var gotoanc = "<a href='#blah'>go to blah</a>"; var anc = "<a name='blah'></a>blah"; ... document.write(gotoanc); ... document.write(anc); i.e. if the string literal does not appear directly as a parameter to document.write but is first assigned to a variable. In an onload or other event handler, even this workaround does not work.
Comment 4•25 years ago
|
||
Attaching a simple testcase that works fine for me under Linux x86 build 2000011308 (RH6.0).
Comment 5•25 years ago
|
||
Reporter | ||
Comment 6•25 years ago
|
||
Your attachment does work for me. I must have been mistaken earlier. However, anchors still do not work when document.written in an event handler like onload, where the entire page is rewritten, or for that matter (as I gather from reading the newsgroups on this topic) when writing to a new window or frame.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M14
Comment 7•25 years ago
|
||
Calling document.write on a document which has been loaded replaces that document. This is expected and documented behavior. In all JavaScript enabled browsers, the following html should produce a page displaying 'hello world' for only for an instant, then replace the text with 'foo'. <html> <body onload="document.write('<html><body>foo</body></html>'); document.close();"> hello world </body> </html>
Reporter | ||
Comment 8•25 years ago
|
||
I understand that the document is replaced if document.write is called after an onload, but the bottom line is that you can't document.write anchors after an onload and have the anchors work correcly - which if not a bug, seems like a pretty severe limitation.
Comment 9•25 years ago
|
||
putting on beta1 radar
Assignee | ||
Comment 11•25 years ago
|
||
*** This bug has been marked as a duplicate of 25712 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•