Closed Bug 762830 Opened 9 years ago Closed 7 years ago
"Clear Authorship Colors" button on etherpad has stopped working on Nightly
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0a1 http://hg.mozilla.org/mozilla-central/rev/7e4c2abb9fc9 1) Go to https://etherpad.mozilla.org/test-clear-authorship 2) Type some text 3) Press the "Clear Authorship Colors" button on the toolbar Expected: Colour highlight on the text you typed disappears. Actual: No colour change and this in the error console... Timestamp: 08/06/2012 10:15:00 Error: TypeError: D is null Source File: https://etherpad.mozilla.org/test-clear-authorship Line: 471 Works fine on Chrome, so not sure if this is platform or Etherpad.
mozilla-central... Last good nightly: 2012-01-16 First bad nightly: 2012-01-17 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=047c8ba7d2e4&tochange=34572943a3e4 mozilla-inbound... Last good nightly: 2012-01-12 First bad nightly: 2012-01-13 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0dbdc8243364&toch ange=4a9747a88eab Moving to Core.
Assignee: nobody → general
Product: Webtools → Core
QA Contact: etherpad → general
Hmm. This is working for me on Mac with a nightly from a few days ago....
I can reproduce in http://hg.mozilla.org/mozilla-central/rev/dc410944aabc Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0a1 ID:20120610030528 The error appears and the command does not work if you do not select any text before click the "Clear Authorship Colors" button. However, No error appears if some text selected. Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/8c24766efc04 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120112 Firefox/12.0a1 ID:20120112134124 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/d41fbe450000 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120112 Firefox/12.0a1 ID:20120112140137 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8c24766efc04&tochange=d41fbe450000 Triggered by: 899a12aeff6c Boris Zbarsky — Bug 716793. Dispatch synthetic mousemove off the refresh driver, not as fast as we can. r=roc We use Flush_Display here because mousemoves flush out layout, so we want to do the synthetic one after we've done our normal layout flushing
Assignee: general → nobody
QA Contact: general → layout
Thank you! :-)
Weird. Is this Windows-specific, then? Why would changing when synthetic mousemoves fire affect JS execution in any way????
I can reproduce on Ubuntu10.40 Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/16 Firefox/16.0a1 ID:20120612030527
(In reply to Boris Zbarsky (:bz) from comment #5) > Weird. Is this Windows-specific, then? Why would changing when synthetic > mousemoves fire affect JS execution in any way???? One more strange thing setting prompts.tab_modal.enabled = false helps
That's really odd. I have no idea why this is being an issue.
Local built(backed Bug 716793 out from tip) fixed the issue...
I don't see the bug on Mac but I do see it on Linux. A simpler testcase might be helpful here.
See several demo site of Etherpad http://etherpad.org/public-sites/ mopad(etherpad.mozilla.org/ – Etherpad V1 hosted by Mozilla)does not work only .... I guess mopad using something older library?
Has worked for some time, forgot to update the bug.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.