Steps to reproduce: 1) Set http://www.mozilla.org/editor/midasdemo/ as your home page or set it so that its the first and only page to load on startup (I'm not sure this is critical to reproducing this bug, I think the text in step 2 may be the critical part). 2) Enter a word, e.g. "notified", set some styling on it, then copy it. 3) Clear out the midas demo text box. 4) Restart Firefox 5) Paste the word into the editor box => If bold text was used at step 2, cursor goes to the beginning of the line => If "formatted" text was used for the style at step 2, Firefox hangs (100% CPU) 6) Move the cursor to the end of the line. 7) Press space 8) Try and paste the text again => Firefox can hang (I've seen it, but not quite worked out the STR for the style). I can reproduce in Thunderbird's compose window as well (using the first compose window and the same procedure). Definitely Broken on: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090513 Shiretoko/3.5b5pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090514 Shredder/3.0b3pre Not sure when this started. Firefox 3 doesn't seem to have this issue, thought it does seem to forget the formatting when copy & pasting.

I've downloaded beta builds today, and a wide regression range appears to be somewhere between Firefox 3.1 beta 2 and Firefox 3.1 beta 3: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3

A narrower regression range would be...helpful. Not blocking on this, but would take a fix.

This is pre beta2 and regressed between the following builds 08110602 and 08110702. Changesets: http://hg.mozilla.org/mozilla-central/rev/f3993df71c29 http://hg.mozilla.org/mozilla-central/rev/18fec592b35b Checkins: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f3993df71c29&tochange=18fec592b35b Mark, could you please verify this range? I can't find any bug which could have been caused this bug. No idea if I have the right range. Thanks!

Works: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090103 Shiretoko/3.1b3pre http://hg.mozilla.org/releases/mozilla-1.9.1/rev/fef0ad965b31 Broken: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090104 Shiretoko/3.1b3pre http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b884fd68ff49 Checkins: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=fef0ad965b31&tochange=b884fd68ff49 => Most likely bug 466599 Note: if in steps to 3 I create a bold notified in 20090103 and copy it to the clipboard and then shutdown and start up in 20090104 for step 5, then the bug doesn't show itself. All steps have to be performed in 20090104 or later.

I haven't managed to reproduce a hang (using FF 3.5 release), but I do see the incorrect cursor position after pasting -- it jumps back to the beginning of the text. Or sometimes it seems to disappear completely, and I have to click again in the editor box to get it back. I suspect this situation may correspond to your "hang"... it's getting confused internally about the cursor position, and if you're unlucky, it heads off into infinite-loop-land somewhere, or stomps on something it shouldn't. Using ClipboardViewer.app to check the contents of the system clipboard, it looks like the formatted (HTML) data there is fine. It's the Paste side of the operation rather than the Copy that is the problem. Bug 466599 enabled Gecko to put HTML on the clipboard, rather than just plain text, which is why you started seeing this problem; before that, the formatting was simply lost. But I'd guess the same thing would happen if a 3rd-party application had put HTML content on the clipboard. I haven't tested that as I'm not sure offhand what applications would use this; most OS X apps using the Cocoa frameworks put RTF on the clipboard as their "rich-text" type. (They automatically convert Gecko's HTML if you copy/paste from Firefox to such applications.)

Jonathan, would you be willing to download a beta (or recent nightly) of Thunderbird 3 and try to reproduce it there?

I've tried recent nightlies of both TBird 3.0beta and 3.1alpha. AFAICT, the issue is unchanged: pasting HTML content (e.g., copied from Firefox) is liable to at least leave the cursor misplaced - usually at the start of document - and possibly hang or crash, with the cursor apparently missing. Sounds just like what I observed in FF 3.5 as well (comment #5). It seems as though it is much more likely to misbehave if the pasted content includes multiple paragraphs; perhaps just "multiple HTML elements" is enough. I think the paste operation is losing track of the relation between the cursor and the elements in the content being edited. Attaching gdb to a hung Thunderbird and interrupting shows a stack like this: Program received signal SIGINT, Interrupt. 0x0101ba30 in NS_CycleCollectorForget2_P () (gdb) bt #0 0x0101ba30 in NS_CycleCollectorForget2_P () #1 0x00fcba69 in NS_TableDrivenQI () #2 0x0048c363 in non-virtual thunk to nsPrintSession::Release() () #3 0x00466075 in non-virtual thunk to nsPrintSession::Release() () #4 0x0078b2c7 in non-virtual thunk to nsPrintSession::Release() () #5 0x0078c731 in non-virtual thunk to nsPrintSession::Release() () #6 0x00788312 in non-virtual thunk to nsPrintSession::Release() () #7 0x006480b4 in non-virtual thunk to nsPrintSession::Release() () #8 0x00838937 in non-virtual thunk to nsPrintSession::Release() () #9 0x00835ef0 in non-virtual thunk to nsPrintSession::Release() () #10 0x005a1064 in non-virtual thunk to nsPrintSession::Release() () #11 0x005a19d9 in non-virtual thunk to nsPrintSession::Release() () #12 0x0059eb25 in non-virtual thunk to nsPrintSession::Release() () #13 0x0059ec6e in non-virtual thunk to nsPrintSession::Release() () #14 0x0059f4d8 in non-virtual thunk to nsPrintSession::Release() () #15 0x0059f6f7 in non-virtual thunk to nsPrintSession::Release() () #16 0x004aa62f in non-virtual thunk to nsPrintSession::Release() () #17 0x004c82e3 in non-virtual thunk to nsPrintSession::Release() () #18 0x004c862f in non-virtual thunk to nsPrintSession::Release() () #19 0x004c8705 in non-virtual thunk to nsPrintSession::Release() () #20 0x004c912b in non-virtual thunk to nsPrintSession::Release() () #21 0x002d44cf in non-virtual thunk to nsPrintSession::Release() () #22 0x002dc8a5 in non-virtual thunk to nsPrintSession::Release() () #23 0x005c1d27 in non-virtual thunk to nsPrintSession::Release() () #24 0x005c3d4b in non-virtual thunk to nsPrintSession::Release() () #25 0x005bda28 in non-virtual thunk to nsPrintSession::Release() () #26 0x002530dc in std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)> () #27 0x0024a152 in std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)> () #28 0x0025cb14 in std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)> () #29 0x00253fbb in std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)> () #30 0x00253d98 in std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)> () #31 0x956081de in -[NSView performKeyEquivalent:] () #32 0x956081de in -[NSView performKeyEquivalent:] () #33 0x95607f47 in -[NSWindow performKeyEquivalent:] () #34 0x00243caf in std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)> () #35 0x95607c0b in -[NSApplication _handleKeyEquivalent:] () #36 0x95524ac7 in -[NSApplication sendEvent:] () #37 0x95481fe7 in -[NSApplication run] () #38 0x0023f7c8 in std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)> () #39 0x00870a67 in non-virtual thunk to nsPrintSession::Release() () #40 0x00007338 in XRE_main () #41 0x00002de3 in start () (gdb)

That stack is unfortunately meaningless, because the build it's from is missing most symbols (it's probably a nightly) and so you get mostly-random functions blamed for it. Also unfortunately, there's no way to trigger breakpad externally on the Mac, so unless it leads to a "natural" crash, getting better data will require a custom build. Mark: can you get it in a debugger in tbird? roc: who would be good to look into this from the layout side?

Yeah, I didn't think the stack was particularly helpful, but just FTR..... This evening I built thunderbird (debug) from current comm-central trunk, hoping to get something more useful, but have not been able to reproduce the hang with this build. I'm still seeing incorrect cursor positioning after HTML paste, as well as inability to undo an HTML paste operation (bug 261392), but despite lots of copy-and-paste, I haven't run into a hang. :( I doubt anything is really fixed, though; it's just not hitting the exact conditions that lead to a hang or crash. I think debugging the incorrect cursor placement is the way to approach this.

I can try again on a debug build but it won't be until after the weekend.

Mats maybe...

Jonathan, you could try using a mozconfig from one of the tinderbox machines (they're displayed in the guts of the buildlog accessible from the relevant tinderbox page) to create a release build with debug symbols. This would make it more likely that you'd hit similar race conditions, and could also generate a better stack trace.

I think the cursor jumping is not due to this patch, but Atul's patch in bug #428096

I sampled a hung process in activity manager today, and end up with the attached stack traces. Saving the stack traces doesn't show the percentage spent in each stack frame, but I'll do that with a screen shot in a moment...

My naive reading of the way these percentages seems to implicate DOM and cycle collector code in this hang as well. peterv (or anyone else who knows that code), are you able to infer anything about what's going on here?

(In reply to comment #17) peterv (or anyone else who knows that > code), are you able to infer anything about what's going on here? Nope, not really. Presumably GetFirstChild is called a lot? It shouldn't be too expensive, but the nsIDOMNode and related APIs are often dominated by QI and AddRef/Release. There's not much we can change about that, we've made various improvements to CC but I think this is as fast as we can make it. This code looks suboptimal overall, switching to nsINode and avoiding AddRefs and Releases might help, for example there's no reason for curNode to be an nsCOMPtr, it's already held by nodeList.

peterv: my understanding is that the hang lasts forever, which is to say that it's not a performance problem, it's some sort of infinite loop. Are you not seeing a way that looping would happen there?

Not with just looking at those stacks, no. Someone needs to step through and figure out where the infinite loop is and why we're not breaking out of it, there's multiple loops in that function.

PeterV: ok, thanks for having a look! Kaze: is this something you'd be able to take a run at?

record and replay might help here?

(In reply to comment #21) > PeterV: ok, thanks for having a look! > > Kaze: is this something you'd be able to take a run at? PeterV: I'm very busy atm but I'll have a look ASAP (= in a couple days).

There has been some recent changes to the code responsible for pasting in HTML editors. Do you still see this problem on a recent nightly?

(In reply to comment #29) > There has been some recent changes to the code responsible for pasting in HTML > editors. Do you still see this problem on a recent nightly? Yes.

Re Comment #30: On the last automatic update (I think it was on 3 August) the bug is still present. (Mac G4 (PPC), OSX 10.4.11)

Further comment re comment #30: My SeaMonkey was updated automatically again this morning (9 am British time) and the bug is still there when copying from MS Word (though not from TextEdit or AppleWorks).

Latest update to comment #32 (10 am British time, 6 Aug): bug still present.

Michael, thanks for confirming the issue, however comment 29 was just asking for a one-off answer. We have that now, so no need to keep commenting.

I can't reproduce this issue and I talk with Mark Banner and he confirmed me that he also can't reproduce this, based on this I will mark this Resolved: WFM. Feel free to reopen if you are can reproduce this.