Closed
Bug 177972
Opened 22 years ago
Closed 22 years ago
Cannot type anything in Editor of MfcEmbed build.
Categories
(Core Graveyard :: Embedding: APIs, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: teruko, Assigned: mjudge)
Details
(Keywords: topembed+)
Attachments
(1 file)
600 bytes,
patch
|
adamlock
:
review+
kinmoz
:
superreview+
asa
:
approval1.3+
|
Details | Diff | Splinter Review |
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•22 years ago
|
QA Contact: depstein → teruko
Comment 4•22 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•22 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•22 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•22 years ago
|
Target Milestone: --- → mozilla1.4alpha
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•22 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•22 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•22 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•22 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•22 years ago
|
||
You need to call MakeWindowEditable _before_ the OpenURL. Or wait until the load is finished, and call MakeWindowEditable(...., PR_FALSE).
Comment 13•22 years ago
|
||
Comment 14•22 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•22 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 17•22 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•22 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 20•22 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•22 years ago
|
||
Fix checked into 1.3 final
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 22•22 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 → ---
Assignee | ||
Comment 24•22 years ago
|
||
gotta get mfc embed up and running again.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
Comment 25•22 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•22 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
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•