Steps to reproduce: 1) Hover the mouse cursor over an item that has a tooltip Actual results: A tooltip appears and disappears right away before a human can read it. Expected results: Expected the tooltip to stay visible until the mouse is moved again.
And the build was: 2001-03-26 FizzillaCFM
Assignee: trudelle → pinkerton
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
moving my osx bugs to 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Tooltips appear to work (sort of) in the 5/09 binary under Mac OS X, v10.0.3. They don't always appear the first time you mouse over something, but they usually do pop up and stay on the screen when they do. Only problem is they're not the right size and never in the right place (apparently, a lot of them appear off-screen). They do look nice with the drop shadow, though.
that's probably because of the other popup/context menu issues we're having right now. once those are fixed, i expect it to revert to "normal" behavior.
patch attached. it seems |event.when| is not what we think it should be on osx. switching to using ::TickCount() seems to fix it and not cause any adverse effects on os9. I tested - timers in mail - click hold context menus - animated gifs - tooltips timing out - urlbar autocomplete widget anything else i should test?
Whiteboard: OSX → OSX, needs r/sr/a
i put in some printf's on macos9 and we seem to always be within 5 ticks (5/60 sec) from event.when. Is that good enough?
Sounds good to me. We should probably try to use higher-resolution time values for timers anyway. Maybe pav's impl will fix that.
r=pchen, can i get sr?
a= firstname.lastname@example.org for checkin to the trunk. (on behalf of drivers)
fixed on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: OSX, needs r/sr/a → OSX
Marking verified in the June 5th Fizzilla build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.