Closed Bug 22850 Opened 25 years ago Closed 24 years ago

Anchors created by document.write don't work.

Categories

(Core :: DOM: HTML Parser, defect, P3)

defect

Tracking

()

VERIFIED DUPLICATE of bug 25712

People

(Reporter: sc110, Assigned: eric)

References

()

Details

Attachments

(1 file)

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.
Assignee: mccabe → nisheeth
Component: Javascript Engine → Parser
Guessing HTML parsing.  Nisheeth, can you categorize better?
Assignee: nisheeth → evaughan
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.
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.
Attaching a simple testcase that works fine for me under Linux x86 build
2000011308 (RH6.0).
Attached file simple testcase
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.
Status: NEW → ASSIGNED
Target Milestone: M14
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>
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.
putting on beta1 radar
targeting
Target Milestone: M14 → M15

*** This bug has been marked as a duplicate of 25712 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
vrfy dupe of fixed bug 39716
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: