Closed
Bug 282518
Opened 20 years ago
Closed 20 years ago
Camino acts as if drop list is in a different screen location to its actual position.
Categories
(Camino Graveyard :: HTML Form Controls, defect)
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 281732
People
(Reporter: Stuart.Lamble, Assigned: mikepinkerton)
References
()
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.6 (KHTML, like Gecko) Safari/125.12 Build Identifier: Camino 2004120508 (v0.8+) In any of the discussion threads accessed via the afore-mentioned URL, if I scroll down towards the bottom of the page, there is a drop list, allowing access to other areas within the forums. Clicking on the drop list itself works as expected. However, if I click within roughly the area of the message immediately above the drop list (the rectangular area starting just above the drop list, and ending roughly 1-2 inches above it, on my 15" PowerBook), Camino highlights the drop list. Moving the pointer out of that area whilst still holding the mouse button does nothing; merely releasing the button, however, leads to a seemingly random item on the drop list being selected and the JavaScript associated with it being executed. Reproducible: Always Steps to Reproduce: 1. Access the forums URL: http://www.diveoz.com.au/discussion_forums/default.asp 2. Select a forum. "Hanging on the Deco Line" is a good test case, as it almost always has at least one long thread. 3. Choose a discussion subject that will have a scroll bar (eg: the first page of a multi-page discussion). I haven't tested to see what happens if there is no scroll bar. 4. Scroll down to the bottom of the page. You'll see a drop list, with a caption to the left of it reading "Jump To:" in bold text. 5. Click on any area within a couple of inches, directly above the drop list (but not actually on it.) Actual Results: A seemingly random item is selected, and the associated JavaScript is executed. Expected Results: If the area clicked is a legitimate linked URL, it should access that URL. If it is not, no action should be taken other than the normal actions for a non-hyperlinked area of text.
| Reporter | ||
Comment 1•20 years ago
|
||
Just verified: this bug is still present in 2005021608 (v0.8+). I know, I know; I should've done that before reporting...
Sounds like a diplicate. *** This bug has been marked as a duplicate of 281732 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
| Reporter | ||
Comment 3•20 years ago
|
||
No, it's not a duplicate of bug 281732 to the best of my knowledge. I've noticed the behaviour noted in 281732, and was thinking about reporting it as a bug, but figured enough people would have noticed that it'd be a major dupe. This particular problem has been exhibited, as I noted, since at least 2004120508. 281732 has only come in since 2005020808. I am reasonably certain that they are two distinct bugs. Bug 281732 is a case of the item not changing when it is clicked upon, and I've seen it on a *lot* of different websites. This bug is a case of the item changing when an area close to it, but not actually on it, is clicked, and I've only ever seen it on the diveoz website. I'll keep my eye on bug 281732; when it's marked as resolved, I'll double check, and reopen this bug if it's not fixed at that time. I'm willing to bet that it won't be... (although I'd love to be proven wrong.)
| Reporter | ||
Comment 4•20 years ago
|
||
Picture Stuart eating his words. :-) This one's definitely resolved now. Woo! Thanks.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•