177972 - Cannot type anything in Editor of MfcEmbed build.

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[Teruko Kobayashi]

Cannot type anything in Editor of MfcEmbed build.

Steps of reproduce
1. Launch MfcEmbed build.
2. Create new profile - Launch Browser
3. Select menu File|New Editor Window to open Editor window
4. Try to type anything

Actual result
Cannot type anything in Editor.

Expected result
Can type in Editor.

Tested 11-01-1.0 branch MfcEmbed build.

Comment 1

[Adam Lock]

-> Chak

Comment 2

[Chak Nanga]

->mike

Comment 3

[saari (gone)]

topembed+, we need this test harness working

Comment 4

[David Epstein]

Just to emphasize this is happening in the branch build. In the trunk, it's
crashing because of null entry to MakeWindowEditable() (bug 174151 and bug 177995)

Comment 5

[David Epstein]

This is also happening in the trunk build (Mozilla 1.3a Mozilla/5.0 (Windows; U;
WinNT4.0; en-US; rv:1.3a) Gecko/20021112). Probably masked by the crash
described in bug 177995 (selecting New Editor Window), which no longer is
crashing ... In the trunk, editor window now opens, but you can't even get input
focus in the window, and thus can't type anything in. I'll take a look on the
branch as well. 

Comment 6

[David Epstein]

Well the behavior has flip-flopped between trunk and branch! First, there was a
crash on the trunk when the MfcEmbed new editor window was selected; now (1.3
trunk), it doesn't crash, but can't get focus in the window and type anything in
(this bug). On the 1.1 branch, one couldn't type anything in; now (1.2 branch),
it's crashing. Tested with Mozilla 1.2 Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
rv:1.2) Gecko/20021122. The checkins which fixed the crash on the trunk didn't
make it in the branch. I will reopen bug 177995 which was verified for the trunk
fix and put in the summary that this is now crashing on the BRANCH.

Comment 7

[mjudge]

I will fix this Feb 10 monday.  that is I will find out if its still a valid 
bug and tweak mfcembed until it works with new editor apis

Comment 8

[Corey Robert Lucier]

In CMfcEmbedApp::OnNewEditor(), if one swaps the OpenURL("about:blank") with 
the InitEditor() call, all is well (after making sure "html" is specified in 
the MakeWindowEditable(..) call.

Someone should still investigate why one must load a page after setting the 
editable bits...  this is only a workaround.

Comment 9

[Chak Nanga]

Here's the MfcEmbed function which Corey's talking about:
http://lxr.mozilla.org/seamonkey/source/embedding/tests/mfcembed/MfcEmbed.cpp#493

I looked at the code from another (internal) product which embeds the editor, it
does exactly what Corey's workaround does - loads a page *after* setting the
editable bits as shown below:

    rv = mEditingSession->MakeWindowEditable(mDOMWindow, "html", PR_TRUE);
    Navigate("about:blank");

The interesting thing is MfcEmbed used to work fine way back - I'm not sure if
it's the URL loading changes or the editor changes which's causing it to fail now.

Not sure if this matters, but, OpenURL() is asynchronous and the doc is not
fully loaded when the call to MakeWindowEditable() is made.

Comment 10

[Simon Fraser [no longer active]]

> Not sure if this matters, but, OpenURL() is asynchronous and the doc is not
> fully loaded when the call to MakeWindowEditable() is made.

That's fine. That last param to 'MakeWindowEditable' is 'waitForURILoad', which
means that it should be made editable once the doc has loaded.

Comment 11

[Chak Nanga]

Here's what's going on when i looked in the debugger:

1. We call OpenUrl("about:blank") to start the URL load process.

2. URL starts loading and appropriate progress listeners start getting invoked
with document level load notifications (the editor's listener never sees the doc
level progress events since it has'nt registered it's listener yet)

3. We then call nsEditingSession::MakeWindowEditable() which calls
nsEditingSession::PrepareForEditing() which then sets up the WebProgress
listener.[please note that the editor's has missed the doc level load
notifications at this stage]
Basically, we never get here
http://lxr.mozilla.org/seamonkey/source/editor/composer/src/nsEditingSession.cpp#629


4. Eventually we get to
http://lxr.mozilla.org/seamonkey/source/editor/composer/src/nsEditingSession.cpp#688
but "mCanCreateEditor" is false - so we skip that part which eventually makes
the window editable.

Comment 12

[Simon Fraser [no longer active]]

You need to call MakeWindowEditable _before_ the OpenURL. Or wait until the load
is finished, and call MakeWindowEditable(...., PR_FALSE).

Comment 13

[Chak Nanga]

Attachment: Patch to call MakeWindowEditable _before_ the OpenURL

Comment 14

[Chak Nanga]

Comment on attachment 114129 [details] [diff] [review]
Patch to call MakeWindowEditable _before_ the OpenURL

Drivers, This change is pretty trivial and would like to get into 1.3final.
There's not much impact to Mozilla since the change is to the MfcEmbed test
harness...thanks

Comment 15

[Adam Lock]

Comment on attachment 114129 [details] [diff] [review]
Patch to call MakeWindowEditable _before_ the OpenURL

r=adamlock

Comment 16

[Simon Fraser [no longer active]]

You don't say if the patch works...

Comment 17

[Chak Nanga]

Hi Simon, yes the patch does work - i tested it.
Corey Lucier also has confirmed that this approach works (please see comment #8
above)

Comment 18

[kinmoz]

Comment on attachment 114129 [details] [diff] [review]
Patch to call MakeWindowEditable _before_ the OpenURL

sr=[e-mail]

Comment 19

[Chak Nanga]

-> Chak

Comment 20

[Asa Dotzler [:asa]]

Comment on attachment 114129 [details] [diff] [review]
Patch to call MakeWindowEditable _before_ the OpenURL

a=asa(on behalf of drivers) for checkin to 1.3 final.

Comment 21

[Chak Nanga]

Fix checked into 1.3 final

Comment 22

[Teruko Kobayashi]

This was fixed in 1.3.  I verified in 3-4 1.3 mfcembed build, but this is
reproduciable in 3-11 trunk build.  I reopen this.

Comment 23

[saari (gone)]

->mjudge

Comment 24

[mjudge]

gotta get mfc embed up and running again.

Comment 25

[chris hofmann]

wonder if someone can own this for mike? looks like the patch needs to find its
way to the trunk if I read this right.

Comment 26

[kinmoz]

Looks like chak landed this on 02/12/2003:

  mozilla/embedding/tests/mfcembed/MfcEmbed.cpp  revision 1.38

He just didn't mark this bug fixed.