Closed Bug 384862 Opened 17 years ago Closed 17 years ago

Midas crashes, when using drag and drop to move custom XML elements inside the editor

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: georg, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061113 SeaMonkey/1.5a
Build Identifier: XulRunner: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a5pre) Gecko/20070517

Midas crashes, when using drag and drop to move custom XML elements inside the editor.

Reproducible: Sometimes

Steps to Reproduce:
1. Select some elements beginning with text or standard HTML elements and ending with text or standard HTML elements and one or more custom XML elements inside the selection. Do this inside the editor.
2. Now click on this selection and keep the mouse button pressed.
3. Move the selection to somewhere else in the editor.
4. Releases the mouse button

Somethimes you crash now after releasing the mouse button. Sometimese the crash ocures after clicking again into the editor.



The problem occures first time with nighly build from trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a5pre) Gecko/20070517

Could not reproduce with earlier builds from the trunk.

I can not test with later builds from the trunk, because all 1.9.a6pre builds including the nighly from yesterday have other problems that prevent me from testing this. So I do not know, whether the problem is still present or has been fixed.
Do you have a talkback ID of the crash perhaps?
http://kb.mozillazine.org/Talkback

> I can not test with later builds from the trunk, because all 1.9.a6pre builds
> including the nighly from yesterday have other problems that prevent me from
> testing this. So I do not know, whether the problem is still present or has
> been fixed.

Which problems? Known problem which already have been filed?
No, talkback is not invoked only the "send to Microsoft tool". Is the crash reporter.exe the talkback application? Does it need configuration to be invoked automatically after a crash of the xulrunner nighlies?
This bug seems a Windows only bug. I never got it on the Mac. Test on Mac done with Xulrunner trunc from May 25 and newest Xulrunner trunk [Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-DE; rv:1.9a6pre) Gecko/20070623].

Drag and drop in Midas seems to be enabled only, if it Midas is used as a XUL element. Drag and drop is not supported, if Midas is based on HTML only. May be this being an important detail.
Could you give a breakpad id?
The breakpad id's are stored for me at:
C:\Documents and Settings\mw\Application Data\Mozilla\Firefox\Crash Reports\submitted
So it's something similar for you, probably.
On monday I'll look on the computer in the company, whether I find there anywhere in the locations told in http://kb.mozillazine.org/Breakpad any crash data. Does Breakpad also display a window like talkback, when it is invoked or is it a windowless application? The only window I get on such crashes ar the windows from the Microsoft crash reporter, which complains at Microsoft about the crash.

At home on the Mac I do not crash and there is no where any crash data on my Mac.
Yes, Breakpad also displays a window like talkback, but it looks different.
It's a bit smaller. The ui isn't completely finished for it yet.
In this case it wasn't called. Is there anything I can do wrong to accidently disable it? Breakpad resides in the root directory of Xulrunner.
It's a xulrunner build? Where do you download these from?
Which xulrunner app did you use? Where can I download that?
I must look in the company for a link to the archive. The crashing builds are from Gecko/20070517 to Gecko/20070525. The builds between that date an the 1.9a6pre have not been tested by me and weren't in the archive when I tried to get them. The 1.9a6pre builds have other bugs, which prevent me to do the test, so I don't know, whethter the bug is still present on windows or not. It never was present on the Mac.
I 've found a link to the archive in the XUL newsgroup.

This is the first available build with the bug.

http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/2007-05-17-08-trunk/xulrunner-1.9a5pre.en-US.win32.zip
Ok, but how do I run the editor or Firefox (or something else?) from xulrunner?
Where can I download that application?
On Monday I'll ask my collegue to extract a minimum testcase from the application. I think we need it also to investigate in an other problem with midas, which is not platform dependent, so our other problem is probably caused by our self and we have to understand what we did wrong causing the other problem.
Ok, thanks.
With: http://lxr.mozilla.org/seamonkey/source/browser/app/application.ini
and changing the variable, you can send xulrunner crash reports with breakpad.
But it won't work, because the server doesn't have xulrunner symbols and there are no plans on doing that.
With a debug build, you could get a stacktrace.
OK, we'll add the lines to our application.ini to enable the Crash Reporter. Does XulRunner have different Symbols than FF, SM or other toolkit based applications?

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit
Well, you can add those lines, but it is useless, because the server has no symbols for Xulrunner.
Yes, every application has different symbols.
Even with the same source text?

Who is responsible for adding the symbols to the server? Who should be informed?
I've asked this to Ted. This is known, it's not something that is forgotten or something. It's probably not a trivial amount of work to also add symbols for nightly xulrunner trunk builds, every day.
I have a bug on uploading debug symbols for Win32 XULRunner nightly builds to FTP.  That should be sufficient for you to debug crashes in those builds.
Depends on: 381513
Which is your bug number to let us add a CC to watch your bug progress? Does this disturb the server, if Xulrunner sends crash reports before the server knows the symbols? Or is it just useless for the moment while the symbols are not present, if I configure our application to send the crash reports, becomming useful in future, when the symbols are added.
See bug 381513, where Ted added a dependency on.
It's useless now, but after bug 381513 is fixed, it becomes usefull.
However, a testcase or a small xulrunner application that shows the crash would probably also be useful.
With Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a6pre) Gecko/20070624 I actually do not get the crashes. So the bug seems to be fixed. I therefore set resolution now to WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Ok, thanks for looking.
You need to log in before you can comment on or make changes to this bug.