Closed
Bug 248606
Opened 21 years ago
Closed 21 years ago
"arrow" doesn't change to hand over links, links don't get bold font-weight inside frame
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
FIXED
mozilla1.8alpha2
People
(Reporter: martijn.martijn, Assigned: dbaron)
References
()
Details
(Whiteboard: [patch])
Attachments
(2 files)
|
(deleted),
text/html
|
Details | |
|
(deleted),
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040623 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040623 Firefox/0.8.0+
On hovering over the links, you don't see that the mouse pointer is changed to a
'hand', only very briefly.
I will attach a simple testcase:
I don't see the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/2004-06-21
Firefox/0.8.0+
But I see the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/2004-06-23
Firefox/0.8.0+
Although, I have no proof, I think this could be a regression of fixing bug 90289.
Reproducible: Always
Steps to Reproduce:
1. Visit site or testcase
2. Mouseover links
3.
Actual Results:
No "hand" as mouse arrow, no bold text for link
Expected Results:
"hand" as mouse arrow, bold text for link
|
Reporter | |
Comment 1•21 years ago
|
||
To trigger the bug, the page must be in a frame, and the framed page consists
of this:
<html>
<head>
<title>bug</title>
<style>
A:hover { font-weight: bold;}
</style>
</head>
<body>
<div style="text-align:center;">
<a href="http://www.google.com">On hovering this should become bold</a>
</div>
</body>
</html>
This was previously discussed here:
http://forums.mozillazine.org/viewtopic.php?t=90397
Thanks to JoeG for reporting.
checkins to SeamonkeyALL between 2004-06-21 00:00 and 2004-06-23 08:00
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-06-21+00%3A00&maxdate=2004-06-23+08%3A00&cvsroot=%2Fcvsroot
I guess bug 20022 is guilty for this regression.
It kinda works here - if i mouse over the beginning of the sentence in
attachment 151680 [details]. But when mousing in over text located after the first space,
the bug can be seen.
|
||
Comment 5•21 years ago
|
||
(In reply to comment #4)
> It kinda works here - if i mouse over the beginning of the sentence in
> attachment 151680 [details]. But when mousing in over text located after the first space,
> the bug can be seen.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040624
here it works the other way,
- if I´m hovering from right to left, I can hover over the full sentence, wfm
- if I´m hovering from left to right, hovering over the left part of the
sentence, there is no action seen, besides sometimes a short flash of the
cursor. When I´m arriving at the 'e' of 'become bold', the whole sentence gets
bolded, and I can go back, right to left, and it stays bold, as long as I´m on it.
- When I´m hovering from below, same action seen: only 'ecome bold' triggers the
boldening of the link, and the cursor change.
|
Assignee | |
Comment 6•21 years ago
|
||
The problem is that the coordinate conversion code is setting mMouseLocation so
that it's relative to the whole page rather than relative to the frame, even
though the view manager is relative to the frame. This means that when the
:hover causes a reflow, we synthesize a mousemove event with incorrect
coordinates that causes things to go out of :hover.
Yes.. coordinates are skewed.. slide cursor along the line from right to left
and CONTINUE sliding to the left in an imaginary line after it leaves the
visible link: The boldness goes on for a long time.
And I too see the cursor getting jerky now and then while sliding btw
|
|
Assignee | |
Comment 8•21 years ago
|
||
Assignee: events → dbaron
Status: NEW → ASSIGNED
|
|
Assignee | |
Updated•21 years ago
|
OS: Windows 2000 → All
Priority: -- → P2
Hardware: PC → All
Whiteboard: [patch]
Target Milestone: --- → mozilla1.8alpha2
|
|
Assignee | |
Comment 9•21 years ago
|
||
Comment on attachment 151705 [details] [diff] [review]
patch
This patch separates the two coordinate transformations (so they're more like
they used to be before bug 20022), and restores the baseView != view check for
the preexisting one.
Any thoughts on whether I should check the debugging code in. I figure if I
check it in I won't need it anymore, but if I don't I'll have to rewrite it
sometime. :-)
Attachment #151705 -
Flags: superreview?(roc)
Attachment #151705 -
Flags: review?(roc)
Comment on attachment 151705 [details] [diff] [review]
patch
d'oh! I should have caught that. Leave the debug code in.
Attachment #151705 -
Flags: superreview?(roc)
Attachment #151705 -
Flags: superreview+
Attachment #151705 -
Flags: review?(roc)
Attachment #151705 -
Flags: review+
|
|
Assignee | |
Comment 11•21 years ago
|
||
Fix checked in to trunk, 2004-06-25 12:02 -0700.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
|
||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•