Cannot type anything in Editor of MfcEmbed build.

RESOLVED FIXED

Status

()

Core
Embedding: APIs
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: Teruko Kobayashi, Assigned: mjudge)

Tracking

({topembed+})

Trunk
x86
Windows 2000
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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.
(Reporter)

Updated

15 years ago
QA Contact: depstein → teruko

Comment 1

15 years ago
-> Chak
Assignee: adamlock → chak

Comment 2

15 years ago
->mike
Assignee: chak → mjudge

Comment 3

15 years ago
topembed+, we need this test harness working
Keywords: topembed+

Comment 4

15 years ago
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)
Summary: Cannot type anything in Editor of MfcEmbed build. → Cannot type anything in Editor of MfcEmbed (branch) build.

Comment 5

15 years ago
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. 
Summary: Cannot type anything in Editor of MfcEmbed (branch) build. → Cannot type anything in Editor of MfcEmbed build.

Comment 6

15 years ago
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.
Depends on: 177995

Updated

15 years ago
No longer depends on: 177995

Updated

15 years ago
Target Milestone: --- → mozilla1.4alpha
(Assignee)

Comment 7

15 years ago
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
Status: NEW → ASSIGNED

Comment 8

15 years ago
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

15 years ago
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

15 years ago
> 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

15 years ago
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

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

Comment 13

15 years ago
Created attachment 114129 [details] [diff] [review]
Patch to call MakeWindowEditable _before_ the OpenURL

Comment 14

15 years ago
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
Attachment #114129 - Flags: superreview?(sfraser)
Attachment #114129 - Flags: review?(adamlock)
Attachment #114129 - Flags: approval1.3?

Comment 15

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

r=adamlock
Attachment #114129 - Flags: review?(adamlock) → review+

Comment 16

15 years ago
You don't say if the patch works...

Comment 17

15 years ago
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

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

sr=kin@netscape.com
Attachment #114129 - Flags: superreview?(sfraser) → superreview+

Comment 19

15 years ago
-> Chak
Assignee: mjudge → chak
Status: ASSIGNED → NEW

Comment 20

15 years ago
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.
Attachment #114129 - Flags: approval1.3? → approval1.3+

Comment 21

15 years ago
Fix checked into 1.3 final
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 22

15 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 23

15 years ago
->mjudge
Assignee: chak → mjudge
Status: REOPENED → NEW
(Assignee)

Comment 24

15 years ago
gotta get mfc embed up and running again.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.4alpha → mozilla1.5alpha

Comment 25

15 years ago
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.
Target Milestone: mozilla1.5alpha → ---

Comment 26

15 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.