15316 2007-09-29 03:19:46 -0700 Events are executed in designMode 2023-02-06 13:43:41 -0800 1 1 1 Unclassified WebKit HTML Editing 523.x (Safari 3) PC Windows XP UNCONFIRMED P2 Normal --- 0 amla70 webkit-unassigned ahmad.saleem792 ian karlcow mrowe rniwa webkit oldest_to_newest 57321 0 amla70 2007-09-29 03:19:46 -0700 If a document is in designMode I don't think that events should be executed, as they will make the editing harder or even raise errors if they depend on scripts that aren't loaded while the document is being edited. Tested in XP with r25792 IE executes them. Firefox doesn't execute. Opera does execute. Test case following to show that executing events can be annoying. If you want to test how they can raise errors, copy some text from MS Word with comments and paste them, the functions called on the onmouseover and onmouseout events aren't available and they will generate errors in the JS console. 57322 1 16447 amla70 2007-09-29 03:21:54 -0700 Created attachment 16447 testcase This is a simple example of trying to edit a document with an onclick event. Slightly annoying. 57391 2 mrowe 2007-09-29 18:28:44 -0700 I'm not sure that I would consider this a bug. What if I wanted clicking on the link in your example to display a widget where I could configure the text and target of the hyperlink, for example. 57425 3 amla70 2007-09-30 01:51:40 -0700 This message might give a much better explanation, as well as showing that the current behavior doesn't match the HTML5 spec (that might need some refinement). http://lists.w3.org/Archives/Public/public-html/2007Sep/0159.html 57429 4 mrowe 2007-09-30 02:15:39 -0700 You're right, that is much clearer about the specific issue. It sounds like the Firefox behaviour is what is desirable here. Event handlers added on the document from outside should be respected, those defined within the document itself are ignored. 88846 5 ian 2008-08-19 14:43:45 -0700 HTML5 now requires this, though it gets the same effect using quite a different definition: http://www.whatwg.org/specs/web-apps/current-work/#scripting2 1931477 6 ahmad.saleem792 2023-02-06 13:43:28 -0800 I am not sure whether this is intended bug in relation to this or not but in WebKit ToT (259906@main), if you click on link, you get dialog but once you dismiss dialog, the caret move to start of paragraph / line rather than staying at same place and allowing editing to edit link (hyperlink text). In case of Chrome Canary 112 and Firefox Nightly 111, the caret remains at same place as you intended when trying to edit the hyperlink text. 16447 2007-09-29 03:21:54 -0700 2007-09-29 03:21:54 -0700 testcase events_designmode.html text/html 411 amla70 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxodG1sPg0KCTxoZWFkPg0KCQk8dGl0bGU+RXZlbnRzIGFyZSBleGVjdXRlZCBpbiBk ZXNpZ25Nb2RlPC90aXRsZT4NCgkJPHNjcmlwdCBsYW5ndWFnZT0iamF2YXNjcmlwdCI+DQoNCgl3 aW5kb3cub25sb2FkID0gZnVuY3Rpb24oKQ0KCXsNCgkJZG9jdW1lbnQuZGVzaWduTW9kZSA9ICdv bicgOw0KDQoJfQ0KDQoJCTwvc2NyaXB0Pg0KCTwvaGVhZD4NCgk8Ym9keT4NCg0KCQk8cD48YSBo cmVmPSIjIiBvbmNsaWNrPSJhbGVydCgnaGVsbG8nKSI+VGhpcyBpcyBhIGxpbms8L2E+IHdpdGgg YW4gb25jbGljayBoYW5kbGVyLiBUcnkgdG8gY2xpY2sgdG8gZWRpdCBpdC48L3A+DQoJPC9ib2R5 Pg0KPC9odG1sPg0K