See the url, you need to download the testcase to your computer, because of enhanced privileges.

See bug 376426 for a similar problem, but different testcase.

In 1.8 branch bug 386354 this is listed as a regression, but that bug has not been checked in yet. Is it a regression from bug 373586 on trunk? Is it likely to be a stop-ship issue? If so please nominate for blocking1.9 Is it the same as bug 376426 (which was filed after bug 373586 was fixed)?

My *guess* is that this is not a regression but something which can be seen now because bug 373586 (which fixes bug 386254 too) is fixed. The patch for bug 386254 doesn't really change functionality, well, ok editor may stay alive a bit longer.

Make sure that viewmanager's EndUpdateViewBatch gets called. There is anyway null checks for selection, so better to not return too early.

The same patch works fine both in trunk and branches.

Because of bug 386254 adding blocking? flags.

Comment on attachment 270791 [details] [diff] [review] proposed patch Does it even make sense to warn?

Maybe not. That was more for my debugging.

Unfortunately this is not the same problem as bug 376426.

Comment on attachment 270926 [details] [diff] [review] without the warning Checked in to trunk.

Comment on attachment 270926 [details] [diff] [review] without the warning approved for 1.8.1.5 and 1.8.0.13, a=dveditz for release-drivers

Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5pre) Gecko/20070709 BonEcho/2.0.0.5pre Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.13pre) Gecko/20070710 Firefox/1.5.0.13pre The page is still painting properly after clicking on the button. (I had to test the testcase in a chrome:// url, btw). It doesn't even crash anymore ;)

Also verified with current trunk build.