Closed Bug 248606 Opened 20 years ago Closed 20 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)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8alpha2

People

(Reporter: martijn.martijn, Assigned: dbaron)

References

(
URL
)

Details

(Whiteboard: [patch])

Attachments

(2 files)

Most simple testcase, derived from url site
623 bytes, text/html
Details
patch
6.00 KB, 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
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.
Confirming with Mozilla trunk build 2004062308 on WinNT4.0.
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.
(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.
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
Attached patch patch — — Splinter Review 
Assignee: events → dbaron
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Priority: -- → P2
Hardware: PC → All
Whiteboard: [patch]
Target Milestone: --- → mozilla1.8alpha2

    
    

    
  
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+

    
    

    
  
Fix checked in to trunk, 2004-06-25 12:02 -0700.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED

    
    

    
  
Verified. Thanks for fixing this.
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: