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

Status: VERIFIED FIXED

(Toolkit :: UI Widgets, defect)

Description

[Stefan [:stefanh]]

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

Comment 1

[Karsten Düsterloh]

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]

Comment 2

[Stefan [:stefanh]]

works in 2008041801
does not work in 2008041901

Comment 3

[Serge Gautherie (:sgautherie)]

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>

Comment 4

[Serge Gautherie (:sgautherie)]

Attachment: Gecko/2008041801, Venkman exceptions

[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...)

Comment 5

[Serge Gautherie (:sgautherie)]

Attachment: Gecko/2008041902, Venkman exceptions

[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.

Comment 6

[Serge Gautherie (:sgautherie)]

Attachment: Gecko/2008042402, Venkman exceptions

[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.

Comment 7

[Serge Gautherie (:sgautherie)]

[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.

Comment 8

[Serge Gautherie (:sgautherie)]

(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 ?

Comment 9

[Andrew Schultz]

this was caused by 425814

Comment 10

[Stefan [:stefanh]]

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

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch

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.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Attachment: v2

Neil, what you think of this, is this enough? Or who could review this?

Comment 15

[Serge Gautherie (:sgautherie)]

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 16

[Neil Deakin]

Comment on attachment 318156 [details] [diff] [review]
v2

Seems OK to me. Let's have another Neil take a look as well.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

This isn't perfect solution, but neither is the <constructor> only case.
If anyone has better ideas for 1.9, suggestions welcome.

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

(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?

Comment 19

[Stefan [:stefanh]]

(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.

Comment 20

[Serge Gautherie (:sgautherie)]

(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 ?

Comment 21

[Stefan [:stefanh]]

(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). 

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

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...

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 318156 [details] [diff] [review]
v2

Better patch coming

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch

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>

Comment 25

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 318381 [details] [diff] [review]
possible patch

This fixes also bug 395345.

Comment 26

[Mike Beltzner [:beltzner, not reading bugmail]]

Is this only affecting composer? Can we take this on a 1.9 branch without blocking RC1 for it?

Comment 27

[Tony Mechelynck [:tonymec]]

(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".

Comment 28

[mhr]

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.

Comment 29

[Tony Mechelynck [:tonymec]]

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.

Comment 30

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 31

[Olli Pettay [:smaug][[e-mail]]]

I guess there are some extensions, which use <xul:editor>.
Because of this bug, also those extensions might be badly broken.

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

k, peterv; can you please review ASAP?

Comment 33

[Peter Van der Beken [: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;
        ...

Comment 34

[Olli Pettay [:smaug][[e-mail]]]

Attachment: +peterv's comment

Comment 35

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 319531 [details] [diff] [review]
+peterv's comment

a1.9=beltzner

Comment 36

[Tony Mechelynck [:tonymec]]

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.

Comment 37

[dales]

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.

Comment 38

[Stefan [:stefanh]]

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!