As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 337646 - Hang in blank entering secure site dialog after viewing cert for domain name mismatch
: Hang in blank entering secure site dialog after viewing cert for domain name ...
: regression, verified1.8.1
Product: Core Graveyard
Classification: Graveyard
Component: Widget: Mac (show other bugs)
: 1.8 Branch
: PowerPC All
: -- critical (vote)
: mozilla1.8.1beta1
Assigned To: Mark Mentovai
: 338501 339359 (view as bug list)
Depends on:
Blocks: 332579
  Show dependency treegraph
Reported: 2006-05-11 15:31 PDT by Tracy Walker [:tracy]
Modified: 2009-11-21 15:10 PST (History)
9 users (show)
mconnor: blocking1.8.1+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

Patch (requires 312586) (3.01 KB, patch)
2006-05-29 08:38 PDT, Mark Mentovai
jaas: review+
Details | Diff | Splinter Review
1.8 branch version (includes 312586) (17.45 KB, patch)
2006-05-30 11:58 PDT, Mark Mentovai
mark: approval‑branch‑1.8.1+
Details | Diff | Splinter Review

Description User image Tracy Walker [:tracy] 2006-05-11 15:31:10 PDT
This regressed between 2006-05-08-03 and 2006-05-09-09 builds of Bon Echo on Mac (both ppc and intel are affected)

steps to reproduce:
-ensure security.warn_entering_secure is set to *true*
(this gets turned off by default after the first https site visited)
-go to the url given:
-Click View Certificate
View Cert Window:
-Click Close
next dialog:
-Click OK

tested results:
a blank dialog slides out... we're hung.  force quit. or sometimes able to actually Firefox | Quit but then crash.

expected results:
Entering Securing Site warning appears and is dismissable.

work-around is to ensure security.warn_entering_secure is set to *false*  or don't view the cert.

note: I tested the regression window builds on the trunk. they don't show this bug.
Comment 1 User image Mark Mentovai 2006-05-11 15:35:02 PDT
Sounds like my event handling changes.  I'll investigate.
Comment 2 User image Mark Mentovai 2006-05-26 21:40:13 PDT
Event handling changes seem to be the trigger - I also see this in the event handling test build at .  I also see this on the trunk now, probably following bug 338153.
Comment 3 User image Mark Mentovai 2006-05-28 13:35:23 PDT
Looks like we're re-showing the last sheet on a kEventWindowActivated event oddly sent from inside HideSheetWindow.  I'm going to compare this to how we handled activation with WaitNextEvent.
Comment 4 User image Eddie Maddox 2006-05-28 17:33:09 PDT
Perhaps I'm seeing the same:

Mac blue G3, OSX 10.3.9.latest-updates

Bon Echo A3   (a financial institution site)

- login: a half dozen numerals
- password: whatever-you-wish
- next screen: it tries to transfer data from the site,
a blank "sheet" pops down, Hangs!

Ff & work.

Eddie Maddox
Comment 5 User image Mark Mentovai 2006-05-29 08:33:57 PDT
OK, I see the problem.  ShowSheetWindow is being called multiple times to attach a sheet to the same top-level window.  In this case, it's the same sheet being attached twice in a row.  The first attachment is happening in nsMacWindow::Show, the second is happening when reentering nsMacWindow::Show on a kEventWindowActivated event caused by the first ShowSheetWindow call after hiding a parent sheet.  The solution to this bug is to only call ShowSheetWindow to attach a sheet, not if Show is called for a sheet that's already attached.

I'm marking this bug as dependent on bug 312586, because the patch I'm about to post depends on the more robust sheet support that bug 312586 provides.  (Bug 312586 fixes some similar problems.)
Comment 6 User image Mark Mentovai 2006-05-29 08:35:13 PDT
*** Bug 339359 has been marked as a duplicate of this bug. ***
Comment 7 User image Mark Mentovai 2006-05-29 08:38:32 PDT
Created attachment 223697 [details] [diff] [review]
Patch (requires 312586)

This patch was prepared against the trunk, which already has the patch to bug 312586.  I intend to take that patch on the 1.8 branch as well.
Comment 8 User image Mark Mentovai 2006-05-30 08:45:31 PDT
Checked in on trunk.
Comment 9 User image Mark Mentovai 2006-05-30 08:46:14 PDT
Comment on attachment 223697 [details] [diff] [review]
Patch (requires 312586)

Will consolidate with 312586 checkin on branch once it's proven.
Comment 10 User image Nicholas Fagerlund 2006-05-30 10:24:51 PDT
Mark, was this the same behavior that was causing 338501?
Comment 11 User image Mark Mentovai 2006-05-30 10:38:57 PDT
*** Bug 338501 has been marked as a duplicate of this bug. ***
Comment 12 User image Mark Mentovai 2006-05-30 10:39:28 PDT
Yes, I'll do some branch checkins shortly that will fix all sorts of sheet problems.
Comment 13 User image Mark Mentovai 2006-05-30 11:58:47 PDT
Created attachment 223816 [details] [diff] [review]
1.8 branch version (includes 312586)

Checked in on MOZILLA_1_8_BRANCH.
Comment 14 User image Eddie Maddox 2006-05-31 20:39:07 PDT
Still broken, but different now.

Nightly: firefox-2.0a3.en-US.mac.dmg  31-May-2006 16:28   17M
On: Mac blue G3, OSX 10.3.9.all-updates

URL: (Financial institution.)

After giving my acct # and PW,
the next screen Hangs "Transferring data from ...". (Same.)
No sheet drops down. (Different.)
Page is all white. (Same.)

Cannot make BonEcho Stop the transfer,
nor Quit except via Force Quit. (All the same.)

Thank you,
Eddie Maddox
Comment 15 User image LonelyBob 2006-08-22 09:09:48 PDT
Tested with Bon echo updated on 20060822 with Intel Mac OSX 10.4.7
No hang or crash observed. 

After following the steps in Description, Click OK, the Secure site warning is closed and Verisign webpage is downloaded and displayed.

Note You need to log in before you can comment on or make changes to this bug.