preview hover delay in 0.1.2

[ivancho]

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 keystroke
http://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.

[ivancho]

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 <vonavI.n...@gmail.com> 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

[Blair McBride]

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

[ivancho]

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" <unfocu...@gmail.com> 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 <vonavI.n...@gmail.com> wrote:
>
> > could this be the reason?

> >http://hg.toolness.com/ubiquity-firefox/diff/c4a29ca72690/ubiquity/ch...

[coplanar]

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.

[ivancho]

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 <satc...@gmail.com> 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

[Blair McBride]

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

[ivancho]

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" <unfocu...@gmail.com> 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
>

[Blair McBride]

Its sounding more and more like what causes #330....

Although, even weirder that Javascript handled events work fine.

- Blair