[PATCH] 'sending unencrypted data' warning dialog regressions

[David Faure]

On Tuesday 25 November 2003 15:31, Lubos Lunak wrote:
> 
>  Hello,
> 
>  (Yes, I somehow got very used to having this dialog always turned on.) This 
> dialog has several nasty regressions against 3.1.
> 
> 1. - I can quite often reproduce it after clicking on 'Start Query' button in 
> the complex query bugs.kde.org page. The dialog appears, I hit Enter, it 
> appears again, I hit Enter, it ... (you get the idea). The dialog has to be 
> cancelled to actually continue. The important detail here is hitting Enter, 
> with mouse clicking it work. I think the problem is because QDialog reacts 
> and Enter keypress, the dialog closes, and the following Enter keyrelease 
> already goes to KHTML. Which has elements reacting on Enter keyrelease :-/.
> 
>  The enter_keyrelease.patch seems to fix it. At least if I understand 
> correctly that 'm_active' means that the activating event (keypress or 
> mousepress) was done, and the matching release didn't happen yet 
> (HTMLGenericFormElementImpl::defaultEventHandler()).

Didn't Dirk commit this already?

> [...]
> 3. There's actually one more regression - holding Space on the button 
> activates it before Space is released. The fix should be indeed not reacting 
> on keyrelease events comming from autorepeat, but inspecting TextEventImpl() 
> ctor, KHTMLView::dispatchKeyEvent() and KHTMLView::keyPressEvent() makes me 
> little clueless person feel like whoever wrote that was nuts. 
No, I think it's just that the Qt event model and the DOM event model differ.
Qt has 2 events (press,release), the DOM has 3 events (down,press,up)

Well, and the fact that we use a QKeyEvent as a data holder for the TextEventImpl,
so the autorepeat bool is abused for another meaning, apparently (hence the
comment I added to KHTMLView::dispatchKeyEvent).

> Could somebody  
> please explain to me what KHTML_KEYDOWN_EVENT, KHTML_KEYUP_EVENT and 
> KHTML_KEYPRESS_EVENT are supposed to mean?

The DOM events spec would do it better than anyone else :)

>  My guess based on reading the code is that
> - KEYDOWN comes after pressing a key, and also while autorepeating
> - KEYPRESS is the first press, i.e. not while autorepeating (kinda strange 
> that the if() in TextEventImpl ctor has key->isAutoRepeat() ).
I think you mixed up those two.
TextEventImpl says that KEYPRESS is when pressing and while autorepeating.
KEYDOWN is when you press initially ("going down").

The if() isn't strange - man qwidget says that autorepeating leads to repeated
keyReleaseEvents in Qt. But "UP" is only when releasing for good - not during
autorepeat.

> - KEYUP - is releasing the key, also while autorepeating
No, only when releasing (the key goes up).

> (which among other things means that I cannot fix the autorepeating problem 
> with Space above)
If you want to activate when releasing then it should be listening for the dom KEYUP event...
(I haven't looked into your actual problem though)

-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).