could this be the reason? http://hg.toolness.com/ubiquity-firefox/diff/c4a29ca72690/ubiquity/chrome/content/ubiquity.js
maybe I should now submit the reverse bug to http://labs.toolness.com/trac/ticket/330 ie, main ubiquity text field stealing focus from the content-previews On Oct 21, 9:40 pm, ivancho <[EMAIL PROTECTED]> wrote: > I have a bunch of commands that have reasonably detailed preview > windows - where by detailed I mean there are several divs with funky > colours and :hover style modifiers to change their background colour > on mouseOver. > > Since I updated to 0.1.2, the mouse events seem to be delayed before > reaching the preview panel - or somehow Firefox delays the update in > background colour, to the point where the :hover change is at best > useless, and at worst very annoying. The CPU load is negligible, > that's why I think it's a problem with the event pipeline, rather than > FF overload. > > Now I know there was a change that added delay before updating after > each keystrokehttp://hg.toolness.com/ubiquity-firefox/rev/06dd1b229481 > but this should not affect a static preview window, after I've long > stopped typing and I'm just hovering around with the mouse, no? > > Not sure if this is a bug report, so first want to ask here if other > people have observed similar behaviour, or can explain why this is > happening. I guess I'll also try reducing the command delay and see if > that fixes the problem - but this can only be a temporary solution - > we shouldn't have to choose between normal mouse behaviour and > keystroke delay. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ubiquity-firefox" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/ubiquity-firefox?hl=en -~----------~----~----~----~------~----~------~--~---
