180962 - insecure form submission warning pops up twice (in the first tab)

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[David Holmes]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021031 Phoenix/0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021108 Phoenix/0.4  

Enter text in Google's main page INPUT TEXT box (http://www.google.com).
In nightly (Win/binary) builds up to 20021031 hitting enter once got a 
single pop-up warning box.  With builds 20021108,11,14 the pop-up warning 
occurs twice (i.e. ENTER must be hit 3 times in total to submit form.)
- note I unfortunately don't have any of the builds between 
10/31 and 11/08 to test (can do if someone can point me at them.)

Reproducible: Always

Steps to Reproduce:
1. Phoenix under XP ; surf to http://www.google.com
2. enter search term - e.g. phoenix
3. hit <ENTER> key
4. pop-up form submission warning - hit <ENTER> key - in 20021031 build, done.
5. in 200211nn builds get another popup warning (duplicate)
6. hit <ENTER> again, done.

Actual Results:  
depending upon whether Phoenix version was 20021031 build or
20021108 and later ones gets either normal (single) pop-up 
form submission warning or duplicated warning (respectively.)


Expected Results:  
Expected a single warning pop-up.

Comment 1

[David Holmes]

(delphys / 2002-11-19)
bug report UPDATE - neglected to mention the following  

a) either MOUSE click or hitting <ENTER> key gets same (duplicate popup) behavior
b) in all test cases the default unzipping of the Windows nightly build was used

Comment 2

[Asa Dotzler [:asa]]

cleaning up summary. not a conformation.summaries should contain the kinds of
information necessary for locating the bug with queries or within a buglist.
builds affected or not affected belong as part of the description and not the
summary.

Was "repeated mouse click or "ENTER" key required for FORM Submit; single worked
in 20021031 build; broken in 20021108/20021111/20021114"

Comment 3

[Asa Dotzler [:asa]]

*** Bug 181528 has been marked as a duplicate of this bug. ***

Comment 4

[Sébastien Delahaye]

*** Bug 183123 has been marked as a duplicate of this bug. ***

Comment 5

[djk]

I can confirm this behavior on W98, build 20021204.

I imagine this is caused by Satchel, as this bug only shows itself in the first
tab; and Satchel only works in the first tab (bug 177797).

Comment 6

[Jonathan Louie]

still there, phoenix 0.5 (20021207).  can confirm comment 5 that it only occurs
in the first tab. (btw, is it strange to anyone else that i get 10 votes for the
main browser, 5 for chimera, and 100 for phoenix?)

Comment 7

[Erik]

Does this problem still exist? I just tested it using Mozilla/5.0 (Windows; U;
WinNT4.0; en-US; rv:1.3b) Gecko/20030204 Phoenix/0.5 and it seems to work - at
least when I try the provided steps in a new browser-window (with no tabs) - or
do I have to use tabbed browsing to reproduce the problem? Of course I need to
uncheck the checkbox "Alert me whenever..." to get rid off the warning.

Comment 8

[djk]

FYI, this bug is apparantly not related to bug 177797.

I still see it on W98 with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b)
Gecko/20030224 Phoenix/0.5

Comment 9

[djk]

Attachment: quick fix

This has nothing to do with either satchel or tabs (directly).

The browser ctor attempts to initialize session history, global history, and
the security UI (form submit warnings, etc).

In Mozilla, apparantly none of these happen in the initial browser ctor, so
they are (also) initialized in the navigator.js Startup() function.

In Px, all three are also initialized in the browser.js Startup(), but the
security UI turns out to have been initialized via the browser ctor already. 
Therefore, the security UI is initialized twice in the first browser instance,
and you get 2 security dialogs.

I disabled the init in the Startup() function and things seem to work.	Tested
in first tab, second tab, and a second window:

1) form submit appears once when submitting a form unencrypted
2) lock icon correctly appears and disappears when switching between secure and
unsecure tabs
3) lock icon correctly appears and disappears when going to/from a secure site
in a tab

Comment 10

[noririty]

*** Bug 200452 has been marked as a duplicate of this bug. ***

Comment 11

[Jonathan Louie]

was the fix for this checked in?  it seems to be working now, 20030504.

Comment 12

[djk]

WFM now.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030511 Mozilla Firebird/0.6

It doesn't appear that my patch was checked in.  I guess a trunk checkin
inadvertently fixed this bug also.

Comment 13

[Colin Ramsay]

Consensus seems to be WFM. Blake, close?

Comment 14

[noririty]

-> WFM

Comment 15

[Jesse Ruderman]

IsoLnCHiP and I can both reproduce.  Reopening.

Comment 16

[Jesse Ruderman]

*** Bug 260674 has been marked as a duplicate of this bug. ***

Comment 17

[Jesse Ruderman]

Steps to reproduce:
1. In about:config, set security.warn_submit_insecure to true and
security.warn_submit_insecure.show_once to true.  This is the default configuration.
2. In the first tab of a browser window, submit Google search form.
3. When you get the first dialog, check the checkbox and click "Continue".

Result: Another (identical) dialog appear.  Double dialogs continue to appear
whenever you submit insecure forms in the first tab of any window.

Comment 18

[Constantine A. Murenin]

This problem only occurs on the 1.0 Branch, not reproducible with 2004-11-03 mac
trunk build -- on the trunk the dialogue has no checkbox at all, and it shows
only the first time a form is encountered, and then disappears forever on any
subsequent forms. 

Regression -- the problem is not reproducible with Firefox 0.9. Reproducible
with 0.10.1, 1.0rc1, 1.0rc2. 

Bug is reproducible not only on Windows, but on Mac OS X too (tested with
Firefox 0.10.1, 1.0rc2). 

This bug poses the user to either choose super annoying security (two messages
instead of one) or be insecure (no messages at all). It should definitely be
fixed for 1.0. 

Comment 19

[Asa Dotzler [:asa]]

Ben, can you take a look at this and see if it's anything obvious? Seems kinda
ugly. 

Comment 20

[Asa Dotzler [:asa]]

Not going to block but we'd consider an ultralowrisk fix.

Comment 21

[Daniel Veditz [:dveditz]]

This patch does fix the bug. The real fix shouldn't leave these lines commented
out, just remove them.

Comment 22

[Christopher Peters]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Still had this bug on updating form 1.0PR . However applying the attached patch
just now finally fixed the issue, so far no negative aspects to applying it.

Comment 23

[Ulrich Windl]

I see the same effect (any "insecure submission" pop-up appears twice instead of
once) in the official Firefox 1.0 release. The last Mozilla (1.7.3) does not
show that effect. Both running on Windows/XP SP2 (and other fixes, just in case
it would matter). I'm surprised that there isn't a fix already.

Comment 24

[Jun MUTO]

The bug of the first tab can be reproduced on the recent Firefox nightly trunk
build too.
(Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a6) Gecko/20050105 Firefox/1.0+)

Comment 25

[Christopher Peters]

(In reply to comment #23)
> I see the same effect (any "insecure submission" pop-up appears twice instead of
> once) in the official Firefox 1.0 release. The last Mozilla (1.7.3) does not
> show that effect. Both running on Windows/XP SP2 (and other fixes, just in case
> it would matter). I'm surprised that there isn't a fix already.

As a matter of fact, there is a fix (its attached to this bug report). It just
never gets integrated into the main builds, I really dont understand why. 

I personally considder this bug to be a major pain in the behind, as I like
haveing the confirmation (often enough I've noticed something just after
submitting and been glad I could just say cancel and correct the error)

I have manually applyed the fix now allready on at least two computers, and it
works fine, however its annoying to do (lots of possibiltys to make a mistake).
Having this bug around has kept me from updating like more than a dozen computer
from 0.9 to 1.0. Shows you I dont considder it a minor bug ;-)

Comment 26

[Christopher Brewer]

Let's get this bugfix integrated into the main source and released. This is an
ugly problem that detracts from the user experience and diminishes Firefox's
reputation as a credible contender.

Comment 27

[Daniel Veditz [:dveditz]]

I can't reproduce this anymore in 1.0 or the trunk... what am I doing wrong?

Comment 28

[Christopher Brewer]

Go to www.applerockies.com, select University of Colorado - Colorado Springs,
choose Individual Purchases. Click the green "I Accept" button on the shopping
agreement and notice the two "Security Warning" popups.

Sorry for the crazy details, but it's where I noticed this bug!

Comment 29

[Boris Zbarsky [:bzbarsky]]

This is actually critical, imo, per comments in bug 282784...

Comment 30

[Boris Zbarsky [:bzbarsky]]

So... I'd really like to get the bug this is blocking in for 1.8b2 (since it's
an api change).  Any chance of getting this bug fixed by then?

Comment 31

[Mike Connor [:mconnor]]

Attachment: patch to remove the re-init in browser.js

discussed this with bz, the fix for bug 138012 should have rendered this
completely unneccessary.  Requesting a= for 1.1a so we can take the API change
in bug 282784 as well.	If we get reports of bustage because the browser.xml
ctor fails (extremely doubtful at this juncture) we can add a conditional
re-init here before final, but we don't expect that will ever be necessary.

Comment 32

[Asa Dotzler [:asa]]

Comment on attachment 180452 [details] [diff] [review]
patch to remove the re-init in browser.js

a=asa

Comment 33

[Mike Connor [:mconnor]]

checked in.

Comment 34

[:Gavin Sharp [email: [e-mail]]]

*** Bug 294308 has been marked as a duplicate of this bug. ***

Comment 35

[Phil Ringnalda (:philor)]

*** Bug 300167 has been marked as a duplicate of this bug. ***