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)

PowerPC
macOS
defect
Not set
normal

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.
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
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.)
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.