Lockup when typing in address line

[wcout]

When typing in the address line sometimes when the list of last addresses appears/is updated it comes to a sort of lockup as no more characters are accepted and the address line stays in place when the browser window is moved.

It happens more frequently when deliberately holding down a key and the autorepeat starts.

[clbr]

Please mention your WM. This has never happened to me in JWM or FLWM,
but xfce is known to not work.

In any case, this bug is about window focus, and either a bug of your
WM or one of FLTK. If you can build FLTK and reproduce it in one of the
tests (test/windowfocus or test/twowin), that would help.

[wcout]

Metacity on Ubuntu 14.04. But I don't think it's a focus/WM problem.
For compilation of fifth I am using current FLTK from SVN with ABI compatability disabled.
I tried the FLTK testprograms, but there is no problem with them.

I have to correct myself: "the address line stays in place" is not true, I meant the dropdown window, but even that seems to be normal.

What really locks up is the keyboard. When the "lockup" occurs the effect is, that keyboard handling is dead within whole fifth (no page/up down, ...) but otherwise everything is working. Even the address line is accepting clicks, changes focus and updates to new addresses when selected from the dropdown, but doesn't accept keystrokes.

It has definitely to to with the dropdown menu updating when typing. I had most success when typing the character 'w', because it has the maximum matches (every entry has 'www') in the dropdown. The "lockup" always occurs when the last 'w' of www is typed (but the adress line still show 'ww') or when using backspace (with autorepeat) in a long 'wwwwww..' line when 'www' is reached. It must be a timing problem, because typing slowly doesn't lead to the effect. As mentioned it is easier when using autorepeat, but it also occurs when typing quickly.

[clbr]

I still believe it's focus/WM related, because that's what I saw on
Xfce with 0.1. When the dropdown window is focused, all keypresses go
to it, and it only uses up/down/esc/enter. The others are discarded
essentially. If pressing esc hides the dropdown and lets you resume
typing, it would confirm this.

After updating the dropdown, the code moves the focus back to the
address bar so you can continue typing. This is what doesn't happen in
this case, I believe. I also believe it's a case of the WM trying to be
smart and avoid "focus stealing", even though it's two windows within
the same program.

Still, I cannot reproduce it here on JWM, the WM I mainly use. I have
quite fast autorepeat settings, and w (or any other char) all work
fine. Ubuntu is not a high priority for me, so it may be weeks before I
take a look.

If you'd like to play with it, the place is fl_browser_input.cpp:popup
(). But it's hard to isolate it if it indeed doesn't happen with the
FLTK focus test programs.

[wcout]

Pressing esc has no effect in this situation.

[wcout]

Ok, I guess you are right - it's either something with WM or FLTK.

Changing in fl_browser_input.cpp constructor win->set_non_modal() to win->set_override(), which keeps the window from interacting with the WM, fixes the problem. And it seems to have no other unwanted effect.

[clbr]

Ok, I guess you are right - it's either something with WM or FLTK.

Changing in fl_browser_input.cpp constructor win->set_non_modal() to win->set_override(), which keeps the window from interacting with the WM, fixes the problem. And it seems to have no other unwanted effect.

I'm afraid I can't apply that as a general fix, as it does come with
downsides. In particular it would show on multiple desktops and
interfere with alt-tab.

[wcout]

What about set_tooltip_window() ?

Seems also to fix it and has the perhaps not so unpleasant side effect that it closes, when the browser window is moved.

[wcout]

Oh, I think set_menu_window() is even more appropriate!

[clbr]

Neither of those would work. Both of them have the issue that they can
go under the main window, giving the impression that there is no
dropdown. The current non-modal makes sure it stays above the main
window.

Native FLTK tooltips and menus are either override or modal in addition
to their respective attribute, and both modal and override are
unsuitable for this use. Modal would prevent interaction with the main
window, ie typing in the url bar.

[wcout]

Last try:

set_non_modal();
+
set_menu_window();

Seems to work too.

[clbr]

Yeah, that doesn't regress things here. Please test current git.

[wcout]

Yes, that fixes it - I played for some time now and the lockup doesn't occur any more.

Thanks for putting it in.

[clbr]

Thanks, closing.