[Webkit-unassigned] [Bug 25898] [Gtk] object:text-changed events should be emitted for entries and password text

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Aug 6 00:11:54 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=25898





--- Comment #62 from Mario Sanchez Prada <msanchez at igalia.com>  2010-08-06 00:11:54 PST ---
(In reply to comment #61)
> I'm not sure I understand why you need to call deleteTextFromNode instead of 
> removing the node as before and make there the notification for the 
> accessibility. Am I missing something?

When I wrote that I wanted to support the needs of the signal to be emmitted (which need the offset and count values for a given deletion) both in the case of actively deleting a piece of text as in the case of undoing such an operation.

Hence, as those pieces of information are inside the the DeleteFromTextNode command there, which also provides both the doApply() and doUnapply() methods, I thought that would be the right place to notify accessibility, which makes it also coherent with the cases of InsertIntoTextNode, AppendNode and InsertNodeBefore commands.

But perhaps there's a way also to implement this, both working with do's and undo's, right there in DeleteSelectionCommand. Not sure yet, though. Any thought on this?

> I also don't fully the get the meaning of the change in the order of the 
> checks.

The change in the order is just to make sure we execute the "else if" branches where deleteFromTextNode() is present, even in the case the main "if" branch would be the way to go when removing all the text from a node (so we'd just remove the node, not the text from it first).

So actually there's no new logic there in the general case, just an extra step in the case when removing the node would be needed (removing the text first).

> I'll apply the patch and look at the modified code.

Thanks a lot for your time, Enrica. I'm not 100% sure either about the editing part (that's why I asked you directly) and I really appreciate you trying to help with this stuff.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list