The events ondragover, ondragenter, ondragleave (and ondrop) don't fire on elements in a document viewed in a frame. When viewing the same document in a stand-alone window, the events do fire.
Created attachment 6560 [details] A document A document. Displays JavaScript alerts when the link is dragged over the text "...here".
Created attachment 6561 [details] A frameset A frameset. When the previously attached document is viewed within this frame, the drag events don't fire
Could you attach a working frameset testcase? :) thx!
Created attachment 6568 [details] Frameset
Did it myself :) testcase confirms the behavior.
Hello, we used this features in some big picture workflow webapplikations and we have also trouble with this. We have created a safari package, which used the older webkit from mac OSX 10.4.3. But this can be for us only a short workaround. I'm hope that's the ondrag* functions soon works again in frames. I has posting the bug by burgreport.apple.com. There is also a testcase. Bugreport there ist 4504308. Can you give us a prognosis for bugfix? Kindest regards Thomas Schumann Dresden GERMANY
(In reply to comment #6) > We have created a safari package, which used the older webkit from mac OSX 10.4.3. Do you mean that this worked in 10.4.3, and broke starting with 10.4.4?? The report doesn't mention this.
(In reply to comment #7) > (In reply to comment #6) > > We have created a safari package, which used the older webkit from mac OSX 10.4.3. > Do you mean that this worked in 10.4.3, and broke starting with 10.4.4?? The > report doesn't mention this. Hello, first, sorry for my bad english... This is the situation: - ondrag* events worked in OSX 10.4.3 with Safari 2.0.2 also in framesets. - ondrag* events don't work in OSX 10.4.4 in framesets, only of the self page, where is started the event As workaround for our customer, we has created a safari 2.0.2 package with included webkit framework from mac OSX 10.4.3. (see www.michelf.com/weblog/2005/mutli-safari) . This "personal" Safari can used also in 10.4.4, separately to Safari 2.0.3. But this can be only a temporarly workaround. Thomas Schumann Dresden GERMANY
Thank you for the clarification! Based on this additional information, I'm marking the bug as Regression/P1.
(In reply to comment #9) > Thank you for the clarification! Based on this additional information, I'm > marking the bug as Regression/P1. Fine! Can I hope so, the bug are fixed in the (near) future? Kindest regards Thomas Schumann
What is the expected behavior here? I can see that ondragenter works in WinIE, but other events don't (even when not in a subframe).
Filed bug 10011 for an unrelated issue (assertion failure) discovered with this test case.
Created attachment 9580 [details] test case for ondragover and ondragleave in Safari 2.0.2 and 2.0.3/2.0.4 I don't understand you. We have no problems in WinIE, but in Safari 2.0.3 and higher !! In Safari 2.0.2 works ondragover and ondragleave in single html-sites AND framesets. Under Safari 2.0.3 works ONLY in single html-sites. We have programmed some web-applikations and need's the feature in framesets again. Here a zip with a simple test case (3 html-sites and 2 pictures). Load the frameset.html and drag the blue picture over picture2 in left or right frame. In safari 2.0.2 you see a alert-Messagebox "ondragover" or "ondragleave". In safari 2.0.3) you don't see the message. Load only the left.html and drag the blue picture over picture2. In safari 2.0.2 AND in safari 2.0.3 you see the alert. Thanks for reply Thomas Schumann
(In reply to comment #13) > I don't understand you. We have no problems in WinIE, but in Safari 2.0.3 and > higher !! Thank you for the new test case - it clarifies a lot! Please note that the original test case for this bug doesn't fully work in WinIE (probably because <p> is used there, rather than <img>) - this was the reason for my confusion.
(In reply to comment #14) > Thank you for the new test case - it clarifies a lot! Please note that the > original test case for this bug doesn't fully work in WinIE (probably because > <p> is used there, rather than <img>) - this was the reason for my confusion. Fine. In the moment we have 3 big web-applikation installations, which are using ondrag* events. The discussions with our customers, why safari 2.0.2 and not a current safari version, is a very big problem for us. We needs your help... Kindest regards Thomas Schumann
I have a fix, now struggling with DumpRenderTree to make a test (its dragging delegate does strange things).
Created attachment 11274 [details] proposed fix
Comment on attachment 11274 [details] proposed fix Hmm, now that layout tests work again, I see some unexpected failures - will need to investigate.
Created attachment 11281 [details] proposed fix All layout tests pass now.
Created attachment 11343 [details] proposed fix Updated to cleanly apply to current trunk. Factored out [EventSendingController saveEvent:], as suggested by Mitz (and tested that the patch doesn't break <input type=search> in subframes).
Comment on attachment 11343 [details] proposed fix looks good. editing/selection/select-from-textfield-outwards.html has some commented alerts that can be removed. r=me, nice job!
Landed in r17574
(In reply to comment #22) > Landed in r17574 Is the fix available in the next safari-update? I hope so... Thank you for work. Best regards Thomas
(In reply to comment #23) > Is the fix available in the next safari-update? Most likely, no-one here will be able to answer this - open source contributors have nothing to do with releases from Apple, Omni, Adobe or other vendors, and Apple developers are generally not allowed to discuss future releases. You may try asking via official channels (http://bugreport.apple.com and DTS).
Thanks, but is the fix included in the next webkit-Package? I will make a official entry in the bugreport of apple. There is the problem already known. Have a nice evening. Thomas
(In reply to comment #25) > Thanks, but is the fix included in the next webkit-Package? Are you asking about nightly builds from http://nightly.webkit.org? The fix is not yet there at the moment (the latest build is r17566, while the fix was landed in r17574), but it will be soon. Please let us know how it works!
(In reply to comment #25) > I will make a official entry in the bugreport of apple. There is the problem > already known. Per Comment #6, there is already a Radar bug for this, so no need to file another one: rdar://problem/4504308. If you haven't mentioned that this regression occurred in Safari 2.0.3 in Mac OS X 10.4.4 in that bug, I would definitely do that. Apple doesn't comment on future product releases (except iTV), so there's no telling when this bug will be fixed, but I'm sure the Safari team will be very interested in regressions introduced in a Tiger update.
I have not found Version r17566. But i have tested with latest version r17587 (is this correct?). There ist the functionality back, super!! What can i do now? Awaiting of fix implementation in the next Tiger update from apple team (how David Kilzer wrote)? Best regards Thomas
This has caused a regression in plugin event dispatching, bug 11517.
*** Bug 9056 has been marked as a duplicate of this bug. ***