Closed Bug 48987 Opened 24 years ago Closed 24 years ago

Crash clicking OK in any alert/confirm dialogs

Categories

(Toolkit :: Form Manager, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: bugzilla, Assigned: morse)

Details

(Keywords: crash, regression, smoketest, Whiteboard: [dogfood-])

Build ID: 2000081409

Steps to Reproduce:
(1) Navigate to a site which has a textbox (or many)
(2) Choose Save Form Data from the Edit menu

After the alert pops up notifying the user that the form data has been 
captured, the app crashes (usually in RDF.DLL)
Depends on: 48860
Keywords: crash, nsbeta3
Actually, I think this is just a problem with clicking "OK" in ANY alert 
dialog.  For example, go to an invalid domain which brings up an alert, and 
click OK...boom.  I don't know who this should go to, though.
Keywords: dogfood
Summary: Crash after Edit | Save Form Data → Crash clicking OK in alerts
I'm unable to reproduce this.  Running a build from a tree that I pulled last 
night.
This could be considered a smoketest blocker if you haven't disabled the SSL 
Security Warning dialog (since you need to click OK)...Can anyone else 
reproduce?
Severity: critical → blocker
No longer depends on: 48860
Summary: Crash clicking OK in alerts → Crash clicking OK in any alert/confirm dialogs
I cannot reproduce with 2000-08-13-08 on Win95 with commericial bits.

sairuh, can you try win98?
morse, what OS you on?

Putting on [dogfood-] radar.  If we can get a reproducible test case, maybe ya
can get an nsbeta3+? :-)
Whiteboard: [dogfood-]
Well, no one else can reproduce this but me.  Guess I'll just sit here and 
cry...
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
fwiw, i cannot repro this on linux comm [2000.08.14.12].

however, while i was trying this bug out --i was going to the bugzilla query
page which has a form, http://bugzilla.mozilla.org/query.cgi-- i noticed that
after i captured the form data, the fieldnames had the format of
bugzilla.mozilla.org/query.cgi:fieldname. if this is expected, fine --if not,
i'll file another bug. thx! (btw, it doesn't hinder prefilling the form.)
vrfy 081409 Win98
Status: RESOLVED → VERIFIED
Very strange.  Although this bug is assigned to me and I received initial 
notification when it was opened, I have not been receiving e-mail about any of 
the comments made to this bug report. ????  It was only by accident that I 
happened to return to it just now.

Jan, I'm running on NT.

Sarah, yes those are probably to be expected since bugzilla is not in the list 
of supported forms nor does it ask for the usual information that we capture 
(name, address, etc).  So if you want to capture it, that's fine, and the values 
will be prefilled onto the bugzilla page when you return to it and press 
prefill.  But they won't be prefilled onto any other page.
If anyone still cares, I think the problem here (like bug 49009) was only 
evident if you had XUL cache disabled (which I did).
Product: Core → Toolkit
QA Contact: bugzilla → form.manager
You need to log in before you can comment on or make changes to this bug.