filepicker crashes Mozilla on second press of Open/Browse buttons on web-pages

RESOLVED INVALID

Status

()

Core
XUL
--
critical
RESOLVED INVALID
15 years ago
5 years ago

People

(Reporter: cls, Assigned: Sergei Dolgov)

Tracking

({crash, fixed1.8.1.12, verified1.8.1.12})

Trunk
x86
BeOS
crash, fixed1.8.1.12, verified1.8.1.12
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

711 bytes, patch
Doug Shelton
: review+
Samuel Sidler (old account; do not CC)
: approval1.8.1.12+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
When uploading a new attachment, I see an easily reproducible crash if the
"File:" textfield is not empty.  It doesn't matter if the path given is valid or
not.

If the textfield is empty, then the File Picker dialog comes up without a problem. 

It looks like part of the problem is that defaultText at
http://lxr.mozilla.org/seamonkey/source/widget/src/beos/nsFilePicker.cpp#124
winds up being the last directory portion of the path in the text field.  (ie,
textfield=/boot/home/src/ => defaultText="src")


Here's the stack:

segment violation occurred
BPrivate::TFilePanel::SetSaveText(char const *):
SetSaveText__Q28BPrivate10TFilePanelPCc:
+0062  ec38686e:   *        08468b    movl    0x00000008(%esi), %eax
mozilla-bin:sc
   frame         retaddr
fd0007cc   ec37f41c  BFilePanel::SetSaveText(char const *) + 0000004c
fd0007ec   ed1243fa  nsFilePicker::Show(short *) + 0000012a
fd000910   ed78f3c7  nsFileControlFrame::MouseClick(nsIDOMEvent *) + 000006f7
fd000b18   ecbaef1a  nsEventListenerManager::HandleEvent(nsIPresContext *,
nsEvent *, nsIDOMEvent **, nsIDOMEventTarget *, unsigned int, nsEventStatus *) +
000006ee
fd000ca8   ecd642b4  nsGenericElement::HandleDOMEvent(nsIPresContext *, nsEvent
*, nsIDOMEvent **, unsigned int, nsEventStatus *) + 000008a4
fd000df0   ecbf4cd8  nsHTMLInputElement::HandleDOMEvent(nsIPresContext *,
nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *) + 000008cc
fd001060   ed769c4b  PresShell::HandleEventInternal(nsEvent *, nsIView *,
unsigned int, nsEventStatus *) + 00000127
fd0010a0   ed769b0a  PresShell::HandleEventWithTarget(nsEvent *, nsIFrame *,
nsIContent *, unsigned int, nsEventStatus *) + 0000003a
fd0010d4   ecbb9a7b 
nsEventStateManager::CheckForAndDispatchClick(nsIPresContext *, nsMouseEvent *,
nsEventStatus *) + 000001e3
fd0011a8   ecbb7745  nsEventStateManager::PostHandleEvent(nsIPresContext *,
nsEvent *, nsIFrame *, nsEventStatus *, nsIView *) + 0000053d
fd00122c   ed769dfe  PresShell::HandleEventInternal(nsEvent *, nsIView *,
unsigned int, nsEventStatus *) + 000002da
fd00126c   ed769a79  PresShell::HandleEvent(nsIView *, nsGUIEvent *,
nsEventStatus *, int, int &) + 00000525
fd0012e8   ed9ba29d  nsViewManager::HandleEvent(nsView *, nsGUIEvent *, int) +
00000309
fd0013c8   ed9aef6a  nsView::HandleEvent(nsViewManager *, nsGUIEvent *, int) +
00000026
fd0013e8   ed9b983c  nsViewManager::DispatchEvent(nsGUIEvent *, nsEventStatus *)
+ 00000820
fd00146c   ed9aea34  HandleEvent(nsGUIEvent *) + 00000044
fd00148c   ed127e5d  nsWindow::DispatchEvent(nsGUIEvent *, nsEventStatus &) +
00000049
fd0014a8   ed127ed2  nsWindow::DispatchWindowEvent(nsGUIEvent *) + 00000036
fd0014c8   ed12b3da  nsWindow::DispatchMouseEvent(unsigned int, nsPoint,
unsigned int, unsigned int) + 000000ae
fd00152c   ed12a754  nsWindow::CallMethod(MethodInfo *) + 000002e8
fd0015c0   ed122646  nsAppShell::Run(void) + 000000b6
fd0015e8   ed0e81a8  nsAppShellService::Run(void) + 00000024
fd0015f8   80010d08  main1(int, char **, nsISupports *) + 00000948
fd001718   80011265  main + 00000111
fd001744   8000bd15  _start + 00000061
mozilla-bin:

Updated

15 years ago
Status: NEW → ASSIGNED

Updated

11 years ago
Assignee: jag → Niels.Reedijk
Status: ASSIGNED → NEW

Comment 1

11 years ago
I think we can close this as "worksforme".  In current build of Firefox, the field comes up blank.  when you click on the field (as if to enter text) the filepicker opens immediately and without crashing here.  Neilx, is this still a problem on SeaMonkey?

Comment 2

11 years ago
I'm affraid it won't work, I actually reproduced it. When I'm at my BeOS computer tomorrow, I'll post the way to reproduce this bug.
Niels, of comment 2 - unfortunately "I'm not working on firefox anymore."
QA Contact: jrgmorrison → xptoolkit.widgets
cls, reporter, writes "I removed BeOS from my systems years ago."
Summary: filepicker crash creating bugzilla attachment → filepicker crashes BeOS creating bugzilla attachment
(Assignee)

Comment 5

10 years ago
Looks like it is bad idea to set SaveText if this isn't file Save dialog.
line:
http://lxr.mozilla.org/mozilla1.8/source/widget/src/beos/nsFilePicker.cpp#135

if (!mTitle.IsEmpty()) {
may be replaced with corrected one:
if (!mDefault.IsEmpty() && panel_mode == B_SAVE_PANEL) {
(Assignee)

Comment 6

10 years ago
Created attachment 289328 [details] [diff] [review]
patch

set savetext only if BFilePanel is really in "save" mode
Assignee: Niels.Reedijk → sergei_d
Status: NEW → ASSIGNED
Attachment #289328 - Flags: review?(doug)

Comment 7

10 years ago
Comment on attachment 289328 [details] [diff] [review]
patch

Patch applied and tested to current branch code.  Opened file picker, selected file, clicked OK.  Opened, selected different file, clicked OK.  No crash!  New file name inserted.  Works great.  Requesting approval for 1.8.1.11.
Attachment #289328 - Flags: review?(doug)
Attachment #289328 - Flags: review+
Attachment #289328 - Flags: approval1.8.1.11?

Comment 8

10 years ago
s/clicked OK/clicked Open
(Assignee)

Updated

10 years ago
Summary: filepicker crashes BeOS creating bugzilla attachment → filepicker crashes Mozilla on second press of Open/Browse buttons on web-pages
Comment on attachment 289328 [details] [diff] [review]
patch

Approved for 1.8.1.12; a=ss for release-drivers. Please land as soon as
possible.
Attachment #289328 - Flags: approval1.8.1.12? → approval1.8.1.12+
(Assignee)

Comment 10

10 years ago
Checking in mozilla/widget/src/beos/nsFilePicker.cpp;
/cvsroot/mozilla/widget/src/beos/nsFilePicker.cpp,v  <--  nsFilePicker.cpp
new revision: 1.28.12.1; previous revision: 1.28
done 
Keywords: fixed1.8.1.12
Could someone with access to a BeOS machine verify this fix using the release candidate for Fx20012?

Comment 12

9 years ago
(In reply to comment #11)
> Could someone with access to a BeOS machine verify this fix using the release
> candidate for Fx20012?
> 
Verified fixed in 2.0.0.12pre, built on 20070127.

Updated

9 years ago
Keywords: verified1.8.1.12
Removing the "fixed1.8.1.12" keyword.

Comment 14

5 years ago
AFAIK, the BeOS port is dead, so let's close out this bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.