Closed Bug 49273 Opened 24 years ago Closed 24 years ago

Buttons do not visibly depress on mousedown

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9

People

(Reporter: bryner, Assigned: bryner)

References

Details

(Keywords: helpwanted, platform-parity, polish, Whiteboard: [nsbeta3-][rtm-])

Attachments

(1 file)

patch
784 bytes, patch
Details | Diff | Splinter Review 
Build: 2000-08-16, Linux.

Go into preferences, move the mouse over the Cancel button.  Press and hold the
mouse button down, and make sure not to move the mouse.  The button does not
draw in the "down" state.  If I move the mouse slightly, it then draws in the
down state.

This appears to be Linux only, and perhaps not even all Linux machines (from
#mozilla testing).  I see it all the time though, and akkana was able to
reproduce it as well.
Nominating for beta3 - I think we need to have correct UI feedback.  Also adding
pp keyword.
Keywords: nsbeta3, pp
On my linux box (rh6.1, gnome, elightenment) I get a visual depress of buttons
(either skin). Need to know how common this is for nsbeta3.

By the way, this has some similarity to bug 35284 "onClick fires on blur, not 
button up", although I can't reproduce that bug either, in today's build.
I get visual depress of buttons on mousedown on Linux 2000-08-16 builds.  I have
a trackball so I know I can press the buttons independently of mouse motion. 
This is with XFree86 4.0.1 and gtk+ 1.2.8, FYI.
Ok, I found what was causing this for me.  It's really weird.

I have a sawmill shortcut set as "Button1-Click1" with the action "Raise
transients and pass through click".  Removing that keybinding makes the visual
feedback work fine.

Does this make sense to anyone?  Is there any way it could be finding a
transient window associated with the XUL button?

I should also note that sawmill was NOT stopping mozilla from getting the
mousedown event (I verified that with printfs).  Something else was going on.

I'm seeing it on a machine using kde (didn't try it on my home machine, where I
use sawmill) and I use pointer focus, with left click just passed through to the
window -- it doesn't do any window manager operations like raising the window.
nsbeta3-,->Future, since it is a cosmetic problem limited to a small subset of 
window managers.  HELP WANTED, would take good fix from mozilla contributor.
Status: NEW → ASSIGNED
Keywords: helpwanted
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
A small subset including kde and sawmill?  What window manager consitutes the
majority on linux?  (Honest question: my first guess would have been kde, I
don't even have a second guess.)
I don't think anyone has even demonstrated the extent of this, but it seemed to
be limited to a subset of window managers, and sensitive to particular
click/pointer settings.  The main thing is that it is entirely cosmetic.  We can
still take a fix, I'm just not able to commit engineers to fix this for N6,
unless higher ups tell me to exchange it for one or more other bugs on our list.
 Perhaps one of those KDE developers is also a mozilla user, and will contribute
a fix.
->pavlov
Assignee: trudelle → pavlov
Status: ASSIGNED → NEW
cc: adding myself (from bug 52640, which is dup of this)
I get this with KDE's KWM 0.14 patchlevel, but in an irregular pattern:
2000-09-13-21 -- it doesn't work (shows this bug)
2000-09-15-06 -- it works like a charm (no bug)
2000-09-18-21 -- doesn't work (shows this bug)
> sensitive to particular click/pointer settings
What are the settings to disable this?
I tried all focus settings and forground settings in KDE and get the very same
result (with 2000-09-18-21).
What *really* puzzles me is that this seems not only to depend on the window
manager (I haven't changed anything there for a month), but also from the
snapshot date.
*** Bug 55428 has been marked as a duplicate of this bug. ***
me too (tm). i'm also using sawmill, with the same funky-yet-default
mousebinding bryner mentioned. mozilla is focused when i click and there are no
transients afaict... seems like nsGtkEventHandler isn't grokking something quite
right.

adding more fun keywords, nominating rtm (hopefully tobias can figure out what's
going on here :)
Keywords: polish, rtm
Get Real. rtm-, there is no chance of PDT taking a fix for this in N6.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
*** Bug 45153 has been marked as a duplicate of this bug. ***
*** Bug 45153 has been marked as a duplicate of this bug. ***
Updating summary, this affects HTML form controls as well.

nominating mozilla 0.9.
Keywords: mozilla0.9
Summary: XUL buttons do not visibly depress on mousedown → Buttons do not visibly depress on mousedown
Since this one is getting on my nerves, I'll go ahead and take this... I might
have some time to hack on it soon.
Assignee: pavlov → bryner
Status: NEW → ASSIGNED
setting moz 0.9... blizzard and i are trying to figure out what's going on here.
Target Milestone: Future → mozilla0.9
bryner -- this seems to be fixed (i had noticed it fixed last week). i had
actually assumed you had fixed it and that i had deleted the bugzilla spam.

on the other hand, maybe my sawmill prefs have changed out from under me! i'll
investigate.
Nope, still broken for me.

seems my sawmill^H^H^H^Hfish prefs changed when i upgraded, so i don't see this
anymore. regardless, the fact that this was seen in kde too, the fact that
sawfish never bungled clicks with any other apps, and bryner's 2000-08-17
comments, all mean that this is our bug, and not a wm bug.

i've seen some other toolkit bugs where it would be nice to know what x11 is
thinking (eg. why does the app lose focus when we mouse around menus?) -- are
there any tools to view or log x11 calls / state?
Attached patch patch — — Splinter Review 

    
    

    
  
identical to a patch I came up with. r=saari

    
    

    
  
Looks good to me, too. sr=blizzard

    
    

    
  
Works for me, on kde.
(If it's checked in, how pleased I'll be. :-)

    
    

    
  
Checked in.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
reopening, blake has noted that this checkin causes a regression on win32 - to
reproduce:

Open Find dialog
Position pointer over disabled Find button
Type in text field
Without moving pointer, click left mouse button, note that the button "pressed"
image is not drawn.

Apparently typing in the textfield is generating NS_MOUSE_ENTER events, which
are likely messing up the hover state with this new code.

So, there are a few options:
1) #ifdef the code in nsEventStateManager XP_UNIX
2) Synthesize an NS_MOUSE_MOVE before NS_MOUSE_LEFT_BUTTON_DOWN in the gtk
widget code
3) Always set :hover on the content when we handle the mousedown event

Of these, (3) seems the most appealing to me, but I seem to remember some
problems that would happen because of oncommand events.  saari, can you
elaborate on that?

Should we back out this checkin until we find another way to fix it?

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Wait, are you saying that win32 is generating NS_MOUSE_ENTER events on each key
press?  Man, I wish I had a windows box to test that.  I might expect that it
generates focus change events but not mouse events.  It's so counter-intuitive.

    
    

    
  
<groan> Work around one broken event flow to hit another </groan>

1) is out, I don't want to #ifdef event generation anymore. Causes more problems
than it solves and I keep learning that the hard way over and over...
2) is an option I suppose, but not much different than #ifdef. Keeping the
nastyness in a better place is all.
3) *seems* right at first, but I don't think it is based on oncommand generating
clicks (which is wrong from a certain perspective). Maybe the visual feedback is
desired in that situation too? But I'm worried about messing with mouse based
style when we have no mouse interaction.

First I think we should figure out why we're getting those mouse enter events on
typing. That is just as wacked out as the linux event sequence we're working
around. I may not get to this today, but I'll try and look at it ASAP. The
regression does not sound serious enough to back out IMO, but do whatever you
want bryner.

    
    

    
  
taking saari's advice and marking this as Fixed (again), and filing bug 67528 on
the win32 issues.

Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: