Its sounding more and more like what causes #330.... Although, even weirder that Javascript handled events work fine.
- Blair On Thu, Oct 23, 2008 at 4:10 PM, ivancho <[EMAIL PROTECTED]> wrote: > > Checked and it works fine on Ubuntu, FF 3.0.1, so I guess this is some > arcane MSWin unpleasantness... > > I added an 'onmouseover' handler to my div, and it is firing without > lag... this is totally vexing... > > > On Oct 22, 8:49 pm, "Blair McBride" <[EMAIL PROTECTED]> wrote: >> Lag in :hover styles is in no way related to any blur event handling, >> or the preview delay. But it could be related to the *cause* of bug >> #330 (but not its fix). >> >> Interesting that everything is fine in the development harness... >> >> - Blair >> >> On Thu, Oct 23, 2008 at 9:03 AM, ivancho <[EMAIL PROTECTED]> wrote: >> >> > hg.toolness.com is down (again), but you are probably pointing towards >> > the previewDelay command option. >> >> > Upon further and deeper investigation, it looks like the post-key- >> > press delay didn't make it into the main 0.1.2 build at all, while the >> > previewDelay option has no effect on the __onBlur hack - the delay in >> > there is hardcoded as 100ms. When I set previewDelay at 5s, this >> > delays the rendering of the preview window, but doesn't change the lag >> > afterwards. Similarly, dropping it to 5ms does not help either. >> >> > I tried commenting out the bulk of the __onBlur hack, and sadly this >> > did not fix the problem, while breaking back #330... so evidently the >> > culprit is elsewhere. >> >> > On Oct 22, 9:00 am, coplanar <[EMAIL PROTECTED]> wrote: >> >> 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 -~----------~----~----~----~------~----~------~--~---
