If it is indeed caused by the fix for #330 then you may want to check out this commit - http://hg.toolness.com/ubiquity-firefox/rev/89df0c048222 . Commands can optionally specify their own delay time.
On Oct 22, 9:38 am, ivancho <[EMAIL PROTECTED]> wrote: > yeah, Windoze... > and no, the lag is not brutal, but it's enough to cripple a CSS'd > menu. > > just tested the insert-link command - it relies on similar :hover > behaviour, and it is now similarly delayed.. > > interestingly, when I run my command preview in the harness > chrome://ubiquity/content/harness.xul , there's no lag. Have no idea > what that means. > > On Oct 22, 1:56 am, "Blair McBride" <[EMAIL PROTECTED]> wrote: > > > Its possibly related to #330, but I don't think the hackish fix for > > #330 is the cause of this issue. But then again, I'm not sure exactly > > what could the cause... it could be the same issue that causes #330 in > > the first place. > > > I just tested a :hover style here, and it does seem have some lag. Not > > a massive lag, but a noticeable one. > > > What OS you are running on? Windows? I ask because #330 seems to be > > specific to Windows. > > > - Blair > > > On Wed, Oct 22, 2008 at 3:22 PM, ivancho <[EMAIL PROTECTED]> wrote: > > > > could this be the reason? > > >http://hg.toolness.com/ubiquity-firefox/diff/c4a29ca72690/ubiquity/ch... > > > > 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 -~----------~----~----~----~------~----~------~--~---
