612565 - Unresponsive script when loading EtherPad document (or pages which use the ACE editor)

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[David Burns :automatedtester]

When Accessing http://etherpad.mozilla.com:9000/mozauto-101119 I am suddenly getting an unresponsive script.

This is working fine in Fx4b7. This has been replicated by Dave Hunt in Test automation too.

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

For me, unresponsive script occurs in build:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101115 Firefox/4.0b8pre

Comment 2

[David Burns :automatedtester]

About:BuildConfig details

about:buildconfig
Source

Built from http://hg.mozilla.org/mozilla-central/rev/edf41ff32f08
Build platform
target
i386-apple-darwin10.2.0
Build tools
Compiler 	Version 	Compiler flags
gcc-4.2 -arch i386 	gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -gdwarf-2 -isysroot /Developer/SDKs/MacOSX10.5.sdk -fno-strict-aliasing -fpascal-strings -fno-common -pthread -DNO_X11 -DNDEBUG -DTRIMMED -gdwarf-2 -O3 -fomit-frame-pointer
g++-4.2 -arch i386 	gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) 	-fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -gdwarf-2 -isysroot /Developer/SDKs/MacOSX10.5.sdk -fno-strict-aliasing -fpascal-strings -fno-common -fshort-wchar -pthread -DNO_X11 -DNDEBUG -DTRIMMED -gdwarf-2 -O3 -fomit-frame-pointer
Configure arguments

--target=i386-apple-darwin10.2.0 --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-tests --enable-codesighs --disable-install-strip --enable-debug-symbols=-gdwarf-2
Source

Built from http://hg.mozilla.org/mozilla-central/rev/edf41ff32f08
Build platform
target
x86_64-apple-darwin10.2.0
Build tools
Compiler 	Version 	Compiler flags
gcc-4.2 -arch x86_64 	gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -gdwarf-2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -fno-strict-aliasing -fpascal-strings -fno-common -pthread -DNO_X11 -DNDEBUG -DTRIMMED -gdwarf-2 -O3 -fomit-frame-pointer
g++-4.2 -arch x86_64 	gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) 	-fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -gdwarf-2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -fno-strict-aliasing -fpascal-strings -fno-common -fshort-wchar -pthread -DNO_X11 -DNDEBUG -DTRIMMED -gdwarf-2 -O3 -fomit-frame-pointer
Configure arguments

--target=x86_64-apple-darwin10.2.0 --with-macos-sdk=/Developer/SDKs/MacOSX10.6.sdk --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-tests --enable-codesighs --disable-install-strip --enable-debug-symbols=-gdwarf-2

Comment 3

[Boris Zbarsky [:bzbarsky]]

Are you guys willing to hunt down a regression range?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

As given by Dave on IRC the range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=674f2ed15cea&tochange=edf41ff32f08

Could the patches for content editable elements be the cause of it? I will start a hg bisect.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Bisecting is not possible in this time range because of all that broken patches. I will manually cherry-pick changesets.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Why can't you bisect with broken patches?  Just |bisect -s| the broken changesets, no?

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

As is turned out my local tree was broken since the last bisecting. Have to do a clobber and start over. Will take a bit longer now.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The first bad revision is:
changeset:   57481:54d00e3411ab
user:        Ehsan Akhgari <[e-mail]>
date:        Thu Nov 11 16:40:52 2010 -0500
summary:     Bug 611182 - Part 3: Handle dynamic changes to the editable documents and create/remove the bogus node if needed; r=bzbarsky a=blocking-beta8+

Comment 11

[Alex Limi (:limi) — Firefox UX Team]

I had this same problem, handed it off to Sayre yesterday, and it seems to be fixed in TraceMonkey nightly build from today.

Note that I never saw the "slow script" dialog, it just made my browser hang. I don't think I have ticked the "don't ask me again" on the slow script dialog.

Comment 12

[Alex Limi (:limi) — Firefox UX Team]

Some clarifications:

- I did indeed have the "unresponsive script" set to "don't ask again", but I might have found some buggy behavior there. Will put that in a separate bug.

- By "handing off", I meant that I got Sayre to reproduce the bug on his setup, and he took it from there. In any case, it seems fixed on TraceMonkey nightlies.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Alexander, this bug is a recent m-c regression; the patch that caused it hasn't landed on tracemonkey yet.

Comment 14

[(no longer active)]

Attachment: Patch (v1)

The fix.  I will also attach an automated testcase as soon as I can write one.

Comment 15

[Robert Sayre]

Ah, I see. It wasn't fixed on TM, rather it just wasn't yet occuring.

Comment 16

[(no longer active)]

Attachment: Patch (v1)

Reading Etherpad's source code, I managed to come up with a test case as well.

Comment 17

[(no longer active)]

This is actually a problem with all of the pages which use the ACE editor framework, since the code which triggers this bug is in ACE.  Resummarizing.

Comment 18

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/a80edd37a40a

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101117 Firefox/4.0b8pre ID:20101117030837