1.97 KB, text/html
1.91 KB, text/html
2.11 KB, text/html
which glibc do you use? (rpm -q glibc)
I noticed the buld ID and I suspect this could be related to bug #52612 where drag and drop is not working in the browser itself. If possible, try this is a build that's a few days old (this is only a recent problem) and see if it works.
I am using glibc 2.1.3-15 I am not sure if this bug is related to drag and drop as it doesn't involve the mozilla's own drag and drop engine. While the bug will repro by loading the content the browser I first produced it from a chrome level XUL aplication, id est a page loaded at the prompt with the -chrome option. At that point none of the default browser behaviors are loaded and gecko is the developers canvas. If I get time I will grab an older build and see if it is only a recently introduced problem.
Some additional comments on Drag and Drop... After taking a good look at the URL drag and drop bug 52612 and then playing with Mozilla for a few minutes I can provide a little bit more information. Dragging and Dropping images works just fine. I was able to drag the Mozilla.org banner into a new composer document, no prob. And again, this seems to be a problem either in JS or something with the Level 2 DOM code, the code worked in older builds which didn't support all of the DOM event model, granted as yet I'm not sure if the new build does either. I am not using the browser's Drag and Drop functions, rather I am implementing my own in a chrome level application. When the same code is loaded into a general browser window the default drag and drop action and the behavior implemented by the DOM Level 0 event listener in the last code snippit I included run into conflict with one another. In the earlier example using the Level 2 DOM the conflict should be resolved, but I can't say for certain. My only suggestion would be to modify the code as needed to include an image of some sort and then attempt to run the NS6/M17 verified code on one of those builds so that you can see the behavior I am trying to generate, it seems to work best on a windows platform, the motion is mutch smoother, but it also works on a linux system. I am assuming you will probably just load this in a gereric browser window so I will reiterate my previos statment regarding the conflict between the default drag and drop behvaior and the behavior I am trying to create. It usually doesn't present a problem on the first attampt, but on successive attampts the browser will take over and attempt to perform its own drag and drop action, this leave you with a browser generated icon clinging to your mouse until you click --and I mean click, moving the mouse again is likely to invoke the browser's drag and drop engine again leaving you where you started-- the mouse button again. If you attempt to run the full DOM level 2 implementation in older the NS6/M17 builds it will result in an icont that is infact attached to your mouse until you load another page, or unload the current page. This problem stems from a bug surrounding the removeEventListener method and its apparent lack of support in these builds. There was a bug submitted on this that i read earlier when I first encountered it marking it as fixed, but I have yet to encounter it in a build... I was attempting to verify the bug's actual status in the current code before reopening it. After you have loaded the code in a older build and been exposed to the desired behaviors load the the two libraries alternately in a new build. The NS6/M17 code is ignored if the user is using the Classic skin and will crash the browser if the user is using the Modern skin. The pure Level 2 DOM implementation will lock the browser after a few seconds of dragging and you must kill the process manually which has made in inpossible to test for the correct implementation of removeEventListener as the browser locks up before I can get a change to release the mousebutton and fire the function responsible for that, this is not realated to the skin, however I have not tested it under Windows, so I am unsure as to the bahavior there, I don't have a test box available that I can install a new Moz build as I have to maintain a clean Test box for the current line of development. I apologize of the extensive verbosity, but with all hope it will help you track down the bug better.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updating QA Contact.
QA Contact: janc → lorca
*spam* adding crash keyword...
I tested this on NT on last weeks trunk build and todays PR3 branch build and the samples do not crash. I also tested it on PR3 Linux build from today and it is not crashing. The dragging is working mostly OK. Occasionally the system level drag & drop kicks in, but currently this is what is supposed to happen. Make the functions return false (at least the begin drag) to see if it helps (it should). I am removing the crash keyword. I think this is actually a dup of bug 47022, marking dup. *** This bug has been marked as a duplicate of 47022 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
Whiteboard: [does not crash]
Well, Kudos... I downloaded today's nightly build after recieving the updated via e-mail and it would appear the bug has been fixed... however, I did take the time to test it in the original build I submitted it for and it still crashes that one. Aother kudos on fixing the true level 2 DOM event handling scheme... i.e. 'removeEventHandler' However, this bug is NOT a dup of 47022 this bug was NOT present in the M17 build only the nightly build it was submitted for. The two bugs deal with a different behavior set, 47022 never crashed the browser, I've been to the page and used parts of it as a reference to build parts of my drag and drop engine... and experienced similar problems when trying to keep track of objects... this bug didn't even allow you to get that far.. simply dragging one of the items crashed the browser... if you want to see what I mean download the build I found it in and run it... I took some time to play with the new build and the DOM standard drag and drop engine, for the first time everything works. All of the points I was concerned about appear to have been fixed, so feel free to mark this bug as resolved... but it is not a duplicate.
Ok, thanks for clarification, I will reopen and mark WFM. Sorry for the spam.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.