Bugzilla – Full Text Bug Listing
| Summary: | Text widget: Modify Event not fired for Backspace key in IE | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | juergen.panser |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | ickefickedicke, tbuschto |
| Version: | 1.5 | ||
| Target Milestone: | 1.5 M6 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
juergen.panser
I can reproduce the IE9 issue. It is explained here: http://help.dottoro.com/ljhxklln.php "The oninput event is buggy in Internet Explorer 9. It is not fired when characters are deleted from a text field through the user interface only when characters are inserted. Although the onpropertychange event is supported in Internet Explorer 9, but similarly to the oninput event, it is also buggy, it is not fired on deletion. Since characters can be deleted in several ways (Backspace and Delete keys, CTRL + X, Cut and Delete command in context menu), there is no good solution to detect all changes. If characters are deleted by the Delete command of the context menu, the modification cannot be detected in JavaScript in Internet Explorer 9." This is going to be a problem for us. Deleting by keyboard is manageable, but as they say, for the context menu its going to be hard or impossible. You can catch menu opening, but probably not clicking on it. What we can do is to check for changes on focusout and selection event, that should prevent the server from getting an outdated value, but it won't work for anything that requires a "live" updating. It seems to work with older RAP versions, most likely due to the change from quirksmode to standard mode in IE9. However, i don't see going back to quirksmode as a possible solution. I can't reproduce any problems in IE8. Perhaps you misunderstand how the InputDialog works. It is not firering modifyEvents since it has not modify listener. Changes are detected, but not sent to the server until another event is fired (in this case button selection). This is by design. I did some testing, and i found out that you do get an event on menu close: mouseout OR mousemove (depending on whether you are still over the text). So what you would have to do is detect a menu opening, then check the text content on the next mouseout or mousemove. Horrible workaround, but it can be done. Unless of course we ignore the live-update issue and just detect changes on focusout/defaultSelect, and hope IE10 fixes the issue. The InputDialog would work again with that. *** Bug 372207 has been marked as a duplicate of this bug. *** The bug here may be the same as Bug 372207, but the workaround you suggested can not be duplicated. I use Textwidgets especially as input for filters and the modify-listener to trigger delayed filter jobs. Is ist possible to fire a modify-event for the listening widget manually (by using a KeyListener for instance)? (In reply to comment #4) > The bug here may be the same as Bug 372207, but the workaround you suggested > can not be duplicated. I was unclear. The workaround i mentioned was meant for RAP to work around the browser bug, not for application developers working around the RAP bug. > I use Textwidgets especially as input for filters and the modify-listener to > trigger delayed filter jobs. Is ist possible to fire a modify-event for the > listening widget manually (by using a KeyListener for instance)? If you want to work around the bug in your application, the keylistener might be a way to do it. But if you can, wait for the bug fix. I guess i can fix it in the next few days, one week tops. (Unless i run into more issues.) (In reply to comment #5) > (In reply to comment #4) > > The bug here may be the same as Bug 372207, but the workaround you suggested > > can not be duplicated. > > I was unclear. The workaround i mentioned was meant for RAP to work around the > browser bug, not for application developers working around the RAP bug. > > > I use Textwidgets especially as input for filters and the modify-listener to > > trigger delayed filter jobs. Is ist possible to fire a modify-event for the > > listening widget manually (by using a KeyListener for instance)? > > If you want to work around the bug in your application, the keylistener might > be a way to do it. But if you can, wait for the bug fix. I guess i can fix it > in the next few days, one week tops. (Unless i run into more issues.) This sounds great! (Up to now I use the keylistener-solution) In addition to the remark in comment 1 "I can't reproduce any problems in IE8. Perhaps you misunderstand how the InputDialog works.": The original problem was detected in a wizard. There a page has some text widgets with modify listeners which are used to handle decorators to give the user feedback about the entered data and to enable and disable the next button. I think the main issue is that text.getText() doesn't return the value a user sees in his UI! (In reply to comment #7) > The original problem was detected in a wizard. There a page has some text > widgets with modify listeners which are used to handle decorators to give the > user feedback about the entered data and to enable and disable the next button. Okay, but that kind of scenario works fine for me in IE8, only IE9 has the problem. You can test the modify listener in the Controls Demo in RAP, "Text" tab. You are right, IE8 seems to be working well. I think i have mixed some test results... Fixed in CVS HEAD. There are still very specific scenarios where a change will not be caught instantaneously, specifically when using the menubar of the browser to delte something. There is nothing we can do about it, but the change will be detected with the focusout at the latest. |