Closed Bug 24514 Opened 25 years ago Closed 24 years ago

Tweak open delay, or use an OS setting

Categories

(Core :: XUL, defect, P3)

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

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: BenB, Assigned: akkzilla)

References

Details

(Whiteboard: [PDT-]) 

Menus seem to need 0.5s or so, until they open (not the first open). It slows
action down e.g. for deeply nested bookmarks.

Is this artificially (like in Windows) or for technical reasons?
Assignee: saari → pinkerton
It is an artificial timer like on Windows. Without it mousing around will always

attempt to open submenus, which is *really* onerous. The time delay can be

adjusted however.



Reassigning to pinkerton
Summary: Remove open delay → Tweak open delay, or use an OS setting
updating comment.
*** Bug 273 has been marked as a duplicate of this bug. ***
Target Milestone: M15
m15, not beta material.
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.
Component: XPMenus → XP Toolkit/Widgets: Menus
bulk accepting xpmenu/popup bugs. sigh.
Status: NEW → ASSIGNED
Target Milestone: M15 → M16
moving all defects not directly related to P0 beta2 features off to M18.
Target Milestone: M16 → M18
What is P0?

Adding DOGFOOD
Keywords: dogfood
Putting on PDT- for beta1.
Whiteboard: [PDT-]
Mike, do you know which file is this 500 ms delay hardcoded into?  I remember 
seeing it once upon a time, but of course I wasn't looking for it at the time.  
It was done by Hyatt for bug 5927.  If I can find it, I was thinking of putting 
in some code that, on Windows only, would read the system setting for menu 
speed.
Dean, tnx for giving it a shot. But please try to make it as XP as possible,
because it is also really needed for Linux: 0ms delay is the default for GTK, I
think, i.e. the "*really* onerous" behaviour saari described is normal here (and
I like it). Maybe you could do it the way, bryner did the mouse-wheel support,
i.e. you can set the values in Mozilla, but the default is "use OS setting, if
available".
(Ben, thanks for adding me to the CC: list - obviously I forgot to do that.)

I want to use the OS settings if available, yes.  The problem is, I only know 
how to get those settings on Windows.  Oh, and maybe BeOS.  I might be able to 
do some digging and find out how to get it on Linux, but the better thing to do 
would be to pass it off to someone else to handle.
It's hard to write Linux-specific software on Windows :-). As long as I can set
the value manually (with some reasonable default) on the other platforms, that's
completely OK for now.
Someone beat me to the Windows-specific code, anyway.  On Windows, the submenu 
popup delay is read from the registry.  For all other OSes, it's set to 200 ms.  
The code for this is in nsLookAndFeel::GetMetric(eMetric_SubmenuDelay), found in 
widget\src\<OS>\nsLookAndFeel.cpp.
Dean,

tnx for the tip. I edited the hardcoded value to 0 and it really helps (although

menus are still a bit slow - I hope this will go away with the time).



Filed bug 33417 "Move hardcoded UI values to XML", which is strongly related.




dean, that value should be in nsLookAndFeel in widget/src/windows

Rods just pointed me to this bug.  I have a fix which implements preferences for
the nsLookAndFeel parameters (which will fall back to the current hardcoded
OS-specific parameters for any pref the user has not set) so this will be
tweakable by the user.  Submenu delay is very definitely included in the list
(in fact, it was the main variable I wanted to change).  Would that fix this
bug?  (I think it would, but I might be missing something.)  If so, reassign it
to me and I'll mark it fixed when I check in my changes.
Is your fix for more OSes than Windows?  Because the code's already there to 
read the MenuShowDelay reg value in Windows.
My fix is cross platform.  It will use the C++ code (which, in the windows case,
reads the OS value) if the user doesn't set a pref to override the value.
Sounds like it would be an improvement over what's in nsLookAndFeel currently.  
If I could, I'd reassign it to you.  Can someone do that?
done.
Assignee: pinkerton → akkana
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: M18 → M15
For the record: akk took over bug 33417 "Move hardcoded UI values to XML".

Should this bug 24514 depend on 33417 or be a dup?
Depends on: 33417
The fix has been checked in.

Add a line like
user_pref("ui.submenuDelay", 123);
to your prefs.js or user.js, where 123 is the submenu delay you want (I think
the unit is milliseconds).
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
tested by adding user_pref("ui.submenuDelay", 1000); to my user.js. works fine
with today's opt comm bits on linux and winNT [2000.04.05.09].

however, the submenu delay seems to be ignored on the Mac. is this expected
since the menus are native?
depends on where it is ignored...is it ignored in the popups on the personal 
toolbar, or in the menus off the native menubar?

Yes, that's probably normal.  Try one of the other prefs (hmm, I haven't tested
many of them) ... maybe something like checkboxSize, or textFieldHeight?
seems to be ignored in the native menubar. unable to test the menus in the xp
toolbar or taskbar, bug 34631.
yup, works spiffily on toolbar/taskbar menus too (mac, linux, winNT). (also
works on the main [sub]menus on linux and winNT; n/a on the native mac menus.)
used opt comm M16 bits 2000.04.13.10/09.
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.