Composer is unusable (can't type anything in the window etc)

VERIFIED FIXED in mozilla1.9

Status

()

defect
--
blocker
VERIFIED FIXED
12 years ago
11 years ago

People

(Reporter: stefanh, Assigned: smaug)

Tracking

({regression})

Trunk
mozilla1.9
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 3 obsolete attachments)

Seen on recent trunk. Karsten see it on Linux as well.

STR:

1) Launch Composer
2) Try to type some text into the content area
 --> Nothing happens, no cursor and no text appear
In fact, if I click into the edit area, I get (after patching /toolkit/content/globalOverlay.js::goUpdateCommand to report the actual error):

An error occurred updating the cmd_cut command
[Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIController.isCommandEnabled]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: chrome://global/content/globalOverlay.js :: goUpdateCommand :: line 71"  data: no]
An error occurred updating the cmd_copy command
[Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIController.isCommandEnabled]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: chrome://global/content/globalOverlay.js :: goUpdateCommand :: line 71"  data: no]
An error occurred updating the cmd_delete command
[Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIController.isCommandEnabled]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: chrome://global/content/globalOverlay.js :: goUpdateCommand :: line 71"  data: no]
works in 2008041801
does not work in 2008041901
Steps which I noticed this with:
1. Ctrl+E from a document (<about:> for example) in browser.
2. Click to switch from Normal to HTML Source view. (for example)
2r. The "tab" changes but not the view.

Confirming:

Regressed between
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041801 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
and
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
which gives
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&sortby=Date&hours=2&date=explicit&mindate=2008-04-18+01&maxdate=2008-04-19+03&cvsroot=%2Fcvsroot>
Target Milestone: --- → seamonkey2.0alpha
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041801 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

This build works fine.

(Note that switching to the other tabs generates different exceptions too, but that's not the point of this bug...)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
to
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008042302 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

These builds are broken.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008042402 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

This build is (a little) better:
the view is switched and a |<!DOCTYPE ...| line is displayed;
but it's still widely broken otherwise.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008042502 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008042519 SeaMonkey/2.0a1pre] (SEA-WIN32-TBOX-trunk) (W2Ksp4)

Behave like Gecko/2008042402.

***

(In reply to comment #1)
> In fact, if I click into the edit area, I get (after patching
> /toolkit/content/globalOverlay.js::goUpdateCommand to report the actual error):

(Confirming too:)
With this step instead of step 2, Venkman reports:

Exception ``[Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIController.isCommandEnabled]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goUpdateCommand :: line 71" data: no]'' thrown from function goUpdateCommand(aCommand=string:"cmd_cut") in <chrome://global/content/globalOverlay.js> line 71.

Exception ``[Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIController.isCommandEnabled]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goUpdateCommand :: line 71" data: no]'' thrown from function goUpdateCommand(aCommand=string:"cmd_copy") in <chrome://global/content/globalOverlay.js> line 71.

Exception ``[Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIController.isCommandEnabled]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goUpdateCommand :: line 71" data: no]'' thrown from function goUpdateCommand(aCommand=string:"cmd_delete") in <chrome://global/content/globalOverlay.js> line 71.

***

(In reply to comment #4)
> (Note that switching to the other tabs generates different exceptions too, but
> that's not the point of this bug...)

(That's still true.)

There should be a "root/common" cause to find and fix.
(In reply to comment #6)
> Created an attachment (id=317833) [details]
> Gecko/2008042402, Venkman exceptions
> 
> This build is (a little) better:

Is
{{
2008-04-23 02:04	neil%parkwaycc.co.uk 	mozilla/suite/browser/viewPartialSource.js 	1.12 	1/1  	Port bug 428653 r+sr=jag
}}
what "improved" the behavior (on my steps) ?
If so, could it be that the added |.wrappedJSObject| is not enough to restore full functionality ?
this was caused by 425814
Blocks: 425814
Keywords: regression
If I switch to <HTML> source view, I can (most of the time) type into the content area. If I then switch back to Normal view, I crash. See http://crash-stats.mozilla.com/report/index/68c00e3a-1388-11dd-9ee5-001cc45a2c28 and http://crash-stats.mozilla.com/report/index/baa75954-1388-11dd-81c7-001321b13766
I'll try to look at this asap, hopefully tomorrow.
Of course if anyone familiar with Composer could say whether it is doing something
strange with its <iframe>/<browser>/<editor> elements, especially related to
'load' event or expectations of when the load is started.
Duplicate of this bug: 431121
Posted patch possible patch (obsolete) — Splinter Review
Anyone willing to test?
For me things work ok with the patch.
The bug is that editor binding calls makeEditable only when
constructor runs. But what if a new page is loaded after that?
So I added DOMContentLoader handler. I think that is good enough.

The patch does also seem to fix a pre-bug-425814 bug where in the browser
File->EditPage opens the page in editor but it isn't actually editable.
Before File->EditPage Composer must have been opened with the default empty page.
Component: Composer → XUL Widgets
Product: Mozilla Application Suite → Toolkit
QA Contact: composer → xul.widgets
Target Milestone: seamonkey2.0alpha → ---
Posted patch v2 (obsolete) — Splinter Review
Neil, what you think of this, is this enough? Or who could review this?
Attachment #318156 - Flags: review?(enndeakin)
Attachment #318150 - Attachment is obsolete: true
Comment on attachment 318156 [details] [diff] [review]
v2

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008042801 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

This fixes it for me :-)
Comment on attachment 318156 [details] [diff] [review]
v2

Seems OK to me. Let's have another Neil take a look as well.
Attachment #318156 - Flags: superreview?(neil)
Attachment #318156 - Flags: review?(enndeakin)
Attachment #318156 - Flags: review+
This isn't perfect solution, but neither is the <constructor> only case.
If anyone has better ideas for 1.9, suggestions welcome.
Assignee: nobody → Olli.Pettay
Flags: blocking1.9?
Target Milestone: --- → mozilla1.9
(In reply to comment #13)
> The patch does also seem to fix a pre-bug-425814 bug where in the browser
> File->EditPage opens the page in editor but it isn't actually editable.
> Before File->EditPage Composer must have been opened with the default empty
> page.
Does anyone know if this is a regression? And what could be the regression range?

(In reply to comment #18)
> (In reply to comment #13)
> > The patch does also seem to fix a pre-bug-425814 bug where in the browser
> > File->EditPage opens the page in editor but it isn't actually editable.
> > Before File->EditPage Composer must have been opened with the default empty
> > page.
> Does anyone know if this is a regression? And what could be the regression
> range?
> 

It works on the 1.8 branch. Dunno about the range, though. But neil (R) might know if it regressed recently.
(In reply to comment #18)
> (In reply to comment #13)
> > The patch does also seem to fix a pre-bug-425814 bug where in the browser
> > File->EditPage opens the page in editor but it isn't actually editable.
> > Before File->EditPage Composer must have been opened with the default empty
> > page.
> Does anyone know if this is a regression? And what could be the regression
> range?

Steps to reproduce ?
Which build have you seen this with ?
(In reply to comment #18)
> (In reply to comment #13)
> > The patch does also seem to fix a pre-bug-425814 bug where in the browser
> > File->EditPage opens the page in editor but it isn't actually editable.
> > Before File->EditPage Composer must have been opened with the default empty
> > page.
> Does anyone know if this is a regression? And what could be the regression
> range?
> 

Ah, found it: bug 395345 (caused by bug 237964). 
I think this might be actually the same bug as bug 395345.
The fix for bug 425814 just changed when frames are loaded.
Still debugging to find better fix...
Depends on: 395345
Comment on attachment 318156 [details] [diff] [review]
v2

Better patch coming
Attachment #318156 - Flags: superreview?(neil)
Posted patch possible patch (obsolete) — Splinter Review
This should bring back the old behavior when !mInteractive.
The change was done here http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsEditingSession.cpp&branch=&root=/cvsroot&subdir=mozilla/editor/composer/src&command=DIFF_FRAMESET&rev1=1.50&rev2=1.51 (Bug 237964)
Peter, what do you think of this? I'm trying to keep the change as small as possible, but still get back the 1.8 behavior for <editor>
Attachment #318381 - Flags: review?(peterv)
Comment on attachment 318381 [details] [diff] [review]
possible patch

This fixes also bug 395345.
Is this only affecting composer? Can we take this on a 1.9 branch without blocking RC1 for it?
(In reply to comment #26)
> Is this only affecting composer? Can we take this on a 1.9 branch without
> blocking RC1 for it?
> 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050201 SeaMonkey/2.0a1pre

To me, Composer is totally unusable no matter what I do -- so I don't use it much ;-) when I want to create or edit HTML pages, I use Vim.

I don't know how many people share my situation (or how many of them use Firefox), but if it's any nontrivial percentabe of the userbase it would definitely "look bad" in any release whatsoever.

I don't have the same problem when composing mail (but I only send in plaintext), nor in browser forms. Or maybe I don't understand what you mean by "only Composer".
I guess it's a matter of what the product is supposed to provide.  Seamonkey is the "complete suite" alternative to Firefox + Thunderbird + <a web page composer< + <chat> + <address book>, for all platforms.  IMNSHO, there is no substitute, and I've tried a lot of them.

If it's not going to be "complete," why are you/we bothering with it at all?

I use the composer all the time - it's not a particularly great web page builder or editor, but it does the job reasonably well when elegance is not required, or for a quick update.  I thought that was why it was included in the suite.

It's your call, of course, but you might want to think about the above....

Thanks.
In reply to comment #28
Even if I don't use Composer, I fully agree that no "production release" should be allowed to go out without it included and working. However, I'm also conscious of the fact that Sm2 is still far from "ready for prime time", unlike its sibling Fx3.
Right; I was assuming that SeaMonkey 2 would be built off of 1.9.0.x, not 1.9. If that's the case, I'd rather we not block the release of Firefox 3 on this bug and move it to wanted 1.9.0.x.

Is that OK? Or am I missing something?
I guess there are some extensions, which use <xul:editor>.
Because of this bug, also those extensions might be badly broken.
k, peterv; can you please review ASAP?
Flags: blocking1.9? → blocking1.9+
Whiteboard: [has patch][needs review peterv]
Comment on attachment 318381 [details] [diff] [review]
possible patch

>Index: editor/composer/src/nsEditingSession.cpp
>===================================================================

>+      // To keep pre Gecko 1.9 behavior, setup editor always when !mInteractive.
>+      PRBool needsSetup = !mInteractive;
>+
>+      if (mInteractive) {

I think it would actually make more sense to use mMakeWholeDocumentEditable (which IIRC currently always means !mInteractive).

I'd do:

      PRBool needsSetup;
      if (mMakeWholeDocumentEditable) {
        needsSetup = PR_TRUE;
      }
      else {
        nsCOMPtr<nsIEditor> editor;
        ...
Attachment #318381 - Flags: superreview+
Attachment #318381 - Flags: review?(peterv)
Attachment #318381 - Flags: review+
Attachment #318156 - Attachment is obsolete: true
Attachment #318381 - Attachment is obsolete: true
Attachment #319531 - Flags: approval1.9?
Whiteboard: [has patch][needs review peterv] → [has patch][has review][has approval]
Comment on attachment 319531 [details] [diff] [review]
+peterv's comment

a1.9=beltzner
Attachment #319531 - Flags: approval1.9? → approval1.9+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050700 SeaMonkey/2.0a1pre

Verified on Linux with this hourly build.

I'm not setting VERIFIED yet, since I cannot test on Windows or Mac.
Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050702 SeaMonkey/2.0a1pre

Verified FIXED on WinXP with the nightly build - but with only brief testing.

I'm following suite and not setting VERIFIED pending others checks.
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050701 SeaMonkey/2.0a1pre. Thanks!
Status: RESOLVED → VERIFIED
Whiteboard: [has patch][has review][has approval]
Blocks: 395345
No longer depends on: 395345
You need to log in before you can comment on or make changes to this bug.