[PATCH] 'sending unencrypted data' warning dialog regressions

Lubos Lunak l.lunak at suse.cz
Tue Nov 25 14:31:55 GMT 2003


 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()).

2. - Use Tab to focus some button. Hit Space to activate it. Cancel the 
dialog. The dialog will appear once again. The reason is that in 
HTMLInputElementImpl::defaultEventHandler(), Space is handled twice for 
m_type == SUBMIT || m_type == RESET. Why is it written as te->keyVal() == ' ' 
instead of checking for Qt::Key_Space BTW?

 As clicking on SUBMIT or RESET apparently has the same effect like simply 
activating, I guess they should be removed from one of the if()'s. Sorry, no 
patch, I have no clue about KHTML.

 Please commit the changes if they're ok.

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. Could somebody 
please explain to me what KHTML_KEYDOWN_EVENT, KHTML_KEYUP_EVENT and 
KHTML_KEYPRESS_EVENT are supposed to mean?

 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() ).
- KEYUP - is releasing the key, also while autorepeating
(which among other things means that I cannot fix the autorepeating problem 
with Space above)

 Will anybody mind if I submit a patch that uses the autorepeat flag in a sane 
way, or is there something I'm missing?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enter_keyrelease.patch
Type: text/x-diff
Size: 1478 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20031125/1d98621d/attachment.patch>


More information about the kfm-devel mailing list