Closed Bug 10287 Opened 25 years ago Closed 25 years ago

<li> in href causes link to bring up wrong URL

Categories

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

x86
Windows 95
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: pabloa, Assigned: nisheeth_mozilla)

References

()

Details

Overview Description
I click in a URL and I get another URL.

Steps to Reproduce
1) type: http://www.patagon.com/espanol/community/read.asp?idf=1&pa=1&idp=17993
2) go bottom
3) Click in [(# 17994) RE: Indiocomido y el consenso político. publicado por
indiocomido el 7/21/99 a las 15:47]
4) You'll jump to [(# 17999) RE: Indiocomido y el consenso político. publicado
por Gilgalad el 7/21/99 a las 15:58]  ***WRONG***


Actual Results:
Mozilla jumps to [(# 17999) RE: Indiocomido y el consenso político. publicado
por Gilgalad el 7/21/99 a las 15:58]

Expected Results:
Mozilla must to jump to [(# 17994) RE: Indiocomido y el consenso político.
publicado por indiocomido el 7/21/99 a las 15:47]]


Additional Builds and Plataforms Tested on
Build Id 1999072010
Plataform: Windows 95  v4.00.950.b
Assignee: don → gagan
Component: Browser-General → Necko
Target Milestone: M10
QA Contact: leger → paulmac
paulmac, do you see this with Aug 20 Win M9 build?
Assignee: gagan → rickg
Severity: critical → major
Component: Necko → Parser
Not sure if this is a parser or layout bug, giving to rickg. Here is a
simplified test case. Notice with seamonkey clicking on either First Link or
Second Link will bring up firstlink.html. The <li> inside the HREF is messing up
things, this may be illegal, I don't know, though NSCP4.x doesn't mind.

----------------------------------------

<a HREF="firstlink.html"><li>
(First Link)  </a>
<a HREF="secondlink.html"><li>
(Second Link)
</a>

----------------------------------------
Duplicated with 8/20 M9 build on win95

Thanks for the bug pablo! Me llamo pablo tambien :-)
Summary: Wrong URL → <li> in href causes link to bring up wrong URL
Assignee: rickg → nisheeth
Nisheeth, here's any easy one for you. The links are getting set up wrong in the
content model (but the parser is passing the right data).
Status: NEW → ASSIGNED
Target Milestone: M10 → M12
Accepting bug and setting milestone to M12...
Move non-PDT+ bugs to M13...
Moving non beta-stoppers to M16...
Hi!


ekrock@netscape.com (Eric Krock) told me that write a Simple Test Case from this
bug. I believe that paulmac@netscape.com wrote a very nice one.

I do not understand that I must do.

PD: Paul, sabés hablar español? Yo no se hablar mucho inglés ;-)
Pablo, tu hablas mas englis que yo hablo espanol, pero tu no necessitas escribir
una  'test case' nueva. Este esta bien.  :-)

No se por que senor eric le pregunta por una nueva.
Is this related to bug 3944?
This bug is fixed in the latest build.  Marking worksforme.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
yep, marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.