Version: KDE: 3.1.92 (CVS >= 20031019) (using KDE Devel) Installed from: Compiled sources Compiler: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) CFLAGS=-march=pentium4 -O3 -pipe -fomit-frame-pointer OS: Linux When you select a text with your mouse ( eg. double clicking on a word, selecting by drag-n-drop ) you can't modify it. For instance when you hit 'backspace' or 'delete' key after selecting the text, the text won't be deleted. Also when you hit any key the selection won't be overwritten, nothing happends. This does not apply to the texts selected by keybord -- for instance by ctrl+shift+right arrow.
You're talking about web pages and wonder that you cannot edit them? :-)
I'm sorry I need to clarify this. I'm talking about text fields on web pages (<input> ). Textareas are fine.
Works for me with current CVS, can you confirm?
Yes seems ok now.
*** Bug 66872 has been marked as a duplicate of this bug. ***
Well, this works usually, but not always.. For example, try to report a new bug.. Press Continue when you're asked about duplicate reports.. And then there's input named "shortDesc", try to edit/backspace/whatever it.. Doesn't work here.
I'm also noticing this. Seems to only occur when you type in text, click outside the input field, then hightlight the text that you typed. BTW, I'm running CVS 031112 and it still seems to be present.
Yes, this bug is seems to be present again. But I couldn't find a certain case to regenerate this bug. I'll post it if I can.
*** Bug 68272 has been marked as a duplicate of this bug. ***
I think it's fixed. Please reopen if you got concrete step to step how to reproduce with HEAD
*** Bug 69823 has been marked as a duplicate of this bug. ***
I've updated my kdelibs now and compiled. This bug is still present unfortunetly. It's hard to give a test case. It sometimes happens.
*** Bug 70027 has been marked as a duplicate of this bug. ***
*** Bug 70303 has been marked as a duplicate of this bug. ***
Still happens sometimes
Always reproducible testcase: Alt+F2 "leo:testcase" Return. Works fine when the page is reloaded or the search term is entered in the URL bar of a running Konqueror window.
I can reliably reproduce this with KDE 3.2Beta2 using the procedure described in Bug 69823
I noticed this error while developing some webpages that had inputs fields like text. I assumed it was because I had defined a maxlen and that since the maxlen had been used by the inputed text, the input from the keyboard was ignored when the text was marked. It is "solved" now, since Konqueror now ignores maxlen!!! I have just tried the pages that I had problems with some days ago. Just before Christmas. I'm 100% sure that I could not mark the text and then enter new text if maxlen was fulfilled, but now I can and I can enter just as many characters as I want to. Konqueror completely ingores maxlen
*** Bug 72096 has been marked as a duplicate of this bug. ***
*** Bug 72244 has been marked as a duplicate of this bug. ***
*** Bug 71120 has been marked as a duplicate of this bug. ***
*** Bug 72763 has been marked as a duplicate of this bug. ***
Subject: Just a note, that it is still reproducable, see the #72763 duplicate.
This bug is still very much alive and is greatly annoying. Around 1 out of 4 times when I highlight some text, with the mouse, in an input field with the intention to type some new text to replace it or press delete or backspace to remove it nothing happens. You have to go and place the cursor in the input field so no text is highlighted and then use backspace or delete to remove it before you can type in the replacement. This is with KDE 3.2RC1 , but 3.2Beta2 had the same problem. Never saw this issue with KDE 3.1.x
Subject: kdelibs/khtml CVS commit by savernik: ensure that embedded widgets don't lose their focus if there's no suitable editable element. CCMAIL: 66296-done@bugs.kde.org M +11 -1 khtmlview.cpp 1.610 --- kdelibs/khtml/khtmlview.cpp #1.609:1.610 @@ -2368,6 +2368,16 @@ void KHTMLView::ensureNodeHasFocus(NodeI if (!node) firstAncestor = 0; + DocumentImpl *doc = m_part->xmlDocImpl(); + // ensure that embedded widgets don't lose their focus + if (!firstAncestor && doc->focusNode() && doc->focusNode()->renderer() + && doc->focusNode()->renderer()->isWidget()) + return; + // Set focus node on the document - m_part->xmlDocImpl()->setFocusNode(firstAncestor); +#if DEBUG_CARETMODE > 1 + kdDebug(6200) << k_funcinfo << "firstAncestor " << firstAncestor << ": " + << (firstAncestor ? firstAncestor->nodeName().string() : QString::null) << endl; +#endif + doc->setFocusNode(firstAncestor); emit m_part->nodeActivated(Node(firstAncestor)); }
Great to see a fix go in. This one caused me a lot of grief. I'm wondering (since I have not been able to test this fix yet), if Bug #70447 is related and possibly fixed by this as well?
*** Bug 73248 has been marked as a duplicate of this bug. ***
Agree, bug still present in KDE3.2 RC1 See #72096 Didn't try to apply the patch from Leo Tomas