139814 - Erased message contents after using main menu item: Search the Web

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Olga]

Build: trunk 04/22/02

Overview: Eraised message contents after using main menu item. It happens in
3-pane and Stand Alone windows as well as in Compose window. 
It seems, that instead of opening and refreshing Browser page with new contents,
it mis-cleans message contents window.

Steps to reproduce: 
a) In 3-pane window: with selected message and its contents shown in the Message
body pane: select Tools|Search|Search the Web. Message pane replaces message
content with Net Search Pane browser page.
b) In Compose window:
1. Start writing a message in Compose window.
2. Select Tools|Search|Search the Web - to get Search page.
3. Notice the results:

Actual Results: my message erased! No Browser page loaded.
It is good I worked with saved message as draft! Wow, looks like dataloss. We
can not expect a regular user to have saved message before doing related to this
message Search.

Expected Results: 'Search the Web' page is loaded. Existing message contents is
not harmed.

Comment 1

[Olga]

Confirmed with today's build as well.

Comment 2

[laurel]

Happens same way in editor window. 

Comment 3

[scottputterman]

marking adt1 and reassigning to varada.  Varada, this is probably not yours
since it's happening in other windows, but could you find the right owner. 
cc'ing Blake in case it's from the menu changes.

I'm marking this adt1 because even though I don't think a lot of people will hit
this, it's pretty severe.  When I just did this, I crashed when I hit Don't Save
when I tried to close the compose window.

Comment 4

[sairuh (rarely reading bugmail)]

olga, does this occur in only the trunk, or both the trunk and branch builds?

Comment 5

[Olga]

Confirmed on branch as well. I checked trunk Win2K and Linux. Branch - Linux.
Also found that on 3-pane no actual data loss. After selecting another message
and coming back to harmed one - it shows its contents.
On Linux branch build: tried to Undo this removing context thing and got crash.
May be not related. 

Comment 6

[varada]

Attachment: Patch Ver 1.

Changed the logic to incorporate checking to see if it is a browser window
before attempting to load the search page. On a browser window it automatically
loads the search page if there is an existing browser window and we choose to
search from a mail or compose window it brings up a new browser window with the
results. This can probably be changed or left as the desired behaviour. I was
not sure about other methods to determine if a window was a browser window so
hence this rudimentary comparison check.

Comment 7

[Michael Buckland]

Discussed at mail news bug meeting.  Decided to add RTM from this bug.  This
means fixing this bug is currently planned for RTM.

Comment 8

[Ninoschka Baca]

Branch build 2002-05-22: WinMe, Mac 10.1.3
It's crashing for me after these steps:

1. In Mail select the Compose button
2. Type an address, subject and some text in the body of the message
3. Select Tools|Search|Search the Web and the body text disppears as Olga describes.
4. Select the "x" box to the close the window
5. Select the "Don't Save" button

Actual Results: Crash
Expected Results: No Crash

Talkback report to follow.

Comment 9

[Ninoschka Baca]

Incident ID: 6594482

0x03997438
nsEditor::BeginTransaction
[d:\builds\seamonkey\mozilla\editor\libeditor\base\nsEditor.cpp, line 654]
nsHTMLEditorLog::BeginTransaction
[d:\builds\seamonkey\mozilla\editor\libeditor\html\nsHTMLEditorLog.cpp, line 237]
nsEditorShell::BeginBatchChanges
[d:\builds\seamonkey\mozilla\editor\composer\src\nsEditorShell.cpp, line 4264]
nsMsgCompose::CloseWindow
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 1135]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2028]
XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2744]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3426]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1220]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
2219]
GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 727]
nsWebShellWindow::ExecuteCloseHandler
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 1492]
nsWebShellWindow::HandleEvent
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 465]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 891]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 908]
nsWindow::DispatchStandardEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 929]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3356]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1153]
KERNEL32.DLL + 0x3613 (0xbff63613)
KERNEL32.DLL + 0x248f7 (0xbff848f7

Comment 10

[varada]

nominating for adt1.0.1 and mozilla1.0.1

Comment 11

[scottputterman]

adding adt1.0.1+ for checkin to the 1.0 branch. Please get approval from drivers
before checking in.

Comment 12

[Bill Law]

+  //check to see if this is a browser window before opening.
+  var winType = document.getElementsByAttribute("windowtype", "navigator:browser");
+
+  if ((winType.length > 0) && window._content)

It would be more efficient like this:
  var winType = document.documentElement.getAttribute("windowtype");

  if (window._content && winType == "navigator:browser")

Otherwise, this looks like a good fix.  

Comment 13

[varada]

Attachment: Patch Ver 1.1

Out with the old and in with the new.

Comment 14

[Bill Law]

Comment on attachment 85822 [details] [diff] [review]
Patch Ver 1.1

r=law

And bonus points for showing sufficient context this time!

Comment 15

[David :Bienvenu]

Comment on attachment 85822 [details] [diff] [review]
Patch Ver 1.1

sr=bienvenu

Comment 16

[varada]

Marking Fixed in Trunk.

Comment 17

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 18

[scottputterman]

Please check this into the branch.  If that's already happened, then please
replace the mozilla1.0.1+ with fixed1.0.1

Comment 19

[varada]

Marking fixed1.0.1. fixed in branch

Comment 20

[Olga]

Verified on branch 06/12/02, Win2K, Linux, Mac OSX.