Closed Bug 511050 Opened 16 years ago Closed 16 years ago

google docs spreadsheets toolbar never becomes active in 3.6 nightlies

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Version:
1.9.2 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: blizzard, Assigned: dmandelin)

References

Details

(Keywords: regression)

When trying to edit a google docs spreadsheet in 3.6 nightlies the toolbar never becomes active so you can't do much.
Flags: blocking-firefox3.6?
Keywords: regression, regressionwindow-wanted
It looks like it happened between 7/13 and 7/14: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b9012a18d2c6&tochange=5923620fafe8 I see this error in the console in after load a google docs spreadsheet using the 7/14 build: Error: this[ke][b] is null Source File: https://spreadsheets.google.com/client/js/3804222091-trix_core.js Line: 492 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090714 Minefield/3.6a1pre
--> Core::JS, there was a TM merge in that range and the error implicates a JS issue.
Assignee: nobody → general
Component: General → JavaScript Engine
Flags: blocking-firefox3.6?
Product: Firefox → Core
QA Contact: general → general
Version: 3.6 Branch → 1.9.2 Branch
Blocking; needs assignee.
Flags: blocking1.9.2+
Potentially a duplicate of bug 505516, though I don't get the slow script warning that bug reports. (sorry for bug spam)
I've never seen a slow script warning. Page feels responsive as well. Also there are no errors in the error dialog.
I get errors periodically there, and the Form menu never activates.
Steps to reproduce: 1. Open a Google document in Firefox. This sample spreadsheet is editable : http://spreadsheets.google.com/ccc?key=0AmikoOWTD0bIdF9WRW5jbjJpc2dvQnZuQm5JcXlVU1E&hl=en&invite=CM-Ys5wO 2. Note greyed-out top menu bar (with tools such as bold and alignment)
this all works on an 08/19/2009 tracemonkey nightly
This sounds like an upvar bug and dmandelin has been fixing a bunch of those the last couple days.
Fwiw, I still see this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090821 Namoroka/3.6a2pre (.NET CLR 3.5.30729) ID:20090821052443 So it's possible that a change hasn't made it downstream to me, or it still is an issue.
i see this bug on 3.7 (tm build not yet merge?) Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20090823 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20090823044819
Are we going to land a fix for this? gdocs has been broken for more than 2 weeks now on the 1.9.2 branch, and apparently we have a fix on the tm branch -- what do we have to do so that people can use 3.6 for dogfood again?
The fixes for bug 504797 should take care of it. There is a stopgap fix already there that fixes Google Docs, but doesn't totally fix the underlying problem. I am also working on a more complete fix.
OS: Windows NT → All
Hardware: x86 → All
Mmh, shall we dupe to bug 511050? Looks like the same issue.
Sorry, wrong bug. Do we know what has been caused this bug? regressionwindow-wanted is still set. What is left to code/test?
AFAICT it's a dup of bug 504797: similar kind of problem, and fixed by the same patch. I'll dup it now, we can just reopen if it recurs.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
So, looking at this with Blizzard, now you get a script warning, then a crash. Reopening. If this is really a dupe, fine, but I wanted to make sure this is *really* on our radar. We should fix this ASAP.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Priority: -- → P1
Marking P1.
I'm on 1.9.2 here, not trunk, not tm.
Assignee: general → dmandelin
It's definitely not a dupe of bug 504797. The toolbar is still disabled for recent Minefield nightlies while the crash or script hanging is fixed. So this stands for its own.
Status: REOPENED → ASSIGNED
(In reply to comment #22) > It's definitely not a dupe of bug 504797. The toolbar is still disabled for > recent Minefield nightlies while the crash or script hanging is fixed. So this > stands for its own. What's your config? I just tried it on MacOSX 10.5 with the 9/21 builds for TraceMonkey, trunk, and 1.9.2, and the Google Spreadsheets toolbar WFM on all 3.
My windows machine is Vista. I just tried and it works there, too. (I opened the sample Boriss gave above and also a spreadsheet of mine.) The build I tested: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090921 Namoroka/3.6a2pre about:buildconfig Source Built from http://hg.mozilla.org/releases/mozilla-1.9.2/rev/25e1253030f4 Build platform target i686-pc-mingw32 Build tools Compiler Version Compiler flags cl 14.00.50727.762 -TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 cl 14.00.50727.762 -GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 Configure arguments --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc
(In reply to comment #23) > What's your config? I just tried it on MacOSX 10.5 with the 9/21 builds for > TraceMonkey, trunk, and 1.9.2, and the Google Spreadsheets toolbar WFM on all > 3. I use default nightly builds on 1.9.2 and 1.9.1. Strangely when testing again with the same build as I have used this morning to test bug 504797 it works now. With that build I get a slow script warning again. Shall we move the crash and slow script issue completely to bug 504797 or filing a new bug?
David, maybe an answer to Comment 26? Is this thing still an issue?
I read comment 26 to say that it's no longer crashing, but can get a slow script warning. I saw that problem with the bug in place but I have not seen it since the fix. If we can get some confirmation (including STR and revs used) on a slow script warning, then we can file a new bug.
If that's the case, is do we want to mark this as resolved?
It still crashes my 1.9.2 nightly on a regular basis. (Is that a different bug?)
Chris, can you link a couple of stacks? (then we can tell whether its the same bug)
Doesn't Chris live here now? Wouldn't it help if he walked over and we dropped in on the crash? :)
(In reply to comment #26) > With that build I get a slow script warning again. Shall we move the crash and > slow script issue completely to bug 504797 or filing a new bug? Haven't seen this anymore.
not a P1 unless someone figures out if this crashes or hangs
Priority: P1 → P2
Priority: P2 → P1
ah, it still does, misread the bug.
Chris, does a recent 3.6 build still crashes for you on Windows 7? I run various tests with different types of documents but never got Namoroka and Minefield to crash on Windows 7. It would be great when you can give us some steps how to reproduce if it still crashes for you. Thanks.
After Robert's TM landings we're no longer crashing and I'm no longer getting the slow script warnings on Windows 7. And I could reproduce this reliably so I'm marking this as fixed.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
status1.9.2: --- → beta1-fixed
You need to log in before you can comment on or make changes to this bug.