159859 - google.com - Confirmation about sending unencrypted information is displayed twice

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Boris Bukh]

Platform: Windows 98
Mozilla Build: 2002072104 (1.1 beta)

To reproduce:
1. Enable confirmation about sending unencrypted data
2. Open http://www.google.com
3. Click on "Groups"
4. When the dialog appears, click "Cancel"

Expected Results:
Nothing happens

Actual Results:
The same dialog appears again

Comment 1

[Wesha]

Related to bug 158331 ?

Comment 2

[Mitchell Stoltz (not reading bugmail)]

->PSM, I think

Comment 3

[Stephane Saux]

kai

Comment 4

[Kai Engert [:KaiE:]]

Happens on the trunk only (not on 1.0 branch). Marking as regression.
I see the problem, too. Confirming bug.


The security code's implementation of nsIFormSubmitObserver::Notify is getting
called another time, if we return the user's decision to cancel.

This is not a PSM bug. We need to find out who is calling us twice.

This problem looks indeed similar to bug 158331.


-> Over to form submission.

Comment 5

[Kai Engert [:KaiE:]]

reassigning to form submission

Comment 6

[Alexandru Savulov]

Attachment: reduced testcase

google has 2 onclick handlers (one on the table cell and on the anchor) both
performing the submission of the form.

IE as Mozilla/Netscape performs the submission twice!

This is an evangelism issue, and Google should give me money for reducing their
traffic to half for those links.

There is another thing:

If let's say a click on "Images" is canceled the action for the form remains
the same: "http://www.google.com/imghp" also when clicking on the "Google
Search" button since that click does not manipulate the form action anymore
using javascript. I guess at google nobody likes to do the HTML pages,
everybody is hacking on the engine :-)

Comment 7

[Alexandru Savulov]

to tech evangelism

Comment 8

[Kai Engert [:KaiE:]]

Alexandru, you say we are submitting the form twice.

But I believe we will only submit it twice, if the first submit is canceled!!!

If the user allows to proceed, we do not display a second warning.
That means, if the first load succeeds, no second submit will happen.

On the 1.0 branch, we do not see this behaviour with the same page.
On the 1.0 branch, even if the user cancels, we will not show a second warning.


I believe Google uses two submit handlers, to ensure the page submit will
happen, even if the user does not click at the link text directly, but at the
background of the table cell.


Shouldn't Mozilla be clever enough to execute only one onclick handler?

That seems to be what is happening on the branch.


On the trunk, it seems, if the first submit is canceled, the code continues to
search for other JavaScript handlers and executes the next one it finds.

The return code from the security warning dialog should give enough information
to the caller, to let the JavaScript know that submission was canceled, and that
action should stop.


I suggest we cc some JavaScript people to ask for their opinion.

Comment 9

[Alexandru Savulov]

we have a double form submission protection already built in, but since the
first form submission gets canceled the flag that shows that we are already
submitting will be reset to 0 (what is correct cause we are really not
submitting anything), then js submits a second time and since there is no
submission pending, the whole story starts again. javascript cannot check that
there was already a form submission attempt to the same target, and it was
canceled. that would be a way to complex change that cannot be put into
javascript. when the warning is turned off, we only submit once bu cause in that
case the flag will prevent the second submission. wlso when we don't cancel, the
flag will prevent a second submission.

the only thing that might be wrong in what i said, is that IE is submitting
twice. now i recall that IE has a double submission protection built in too.
however there is no way to make IE asking if the user wants to submit before the
submission occurs cause IE does not warn the users about submitting to normal
(non secure) server from a nonsecure page.

Comment 10

[Kai Engert [:KaiE:]]

Do you understand why this behaviour is not happening on the 1.0 branch?

Comment 11

[Alexandru Savulov]

the warnings are displayed by form submission observers that are registered
dynamically. i have to check what observers have been added/modified recently to
the list of observers managed by "@mozilla.org/observer-service;1". i'm sure
that the observer was added/modified with purpose and the behaviour is right
(mozilla 1.0 does not display the message at all and that is wrong actually).
there is a form submission occuring and the warning must be presented if the
option "P&S/SSL/Sending from unencrypted to unencrypted" is checked. now the
fact that is presented twice, is be cause there is javascript code that tries to
submit twice. the user cancels the first one, thus the second one can be
performed since is not blocked by the first submission. unfortunately there is
no way around this unless we break the initial fix. 

the only way to prevent this would be to add a check to identify the *initiating
event* that triggered the submission (in our case, the click on the "groups"
link on google's portal page). that would require the propagation of an unique
identifier of the form submission triggering event(click, timer, whatever)
trough all our layers (event handling, javascript module,...). only that way we
can reliably prevent a double form submission. however i'm not that sure if this
is an easy task to solve. an event might or might not trigger a form submission.
let's say we get a click event on a random HTML element. Just the click itself
will not trigger form submission. However there could be a js handler (onclick)
that will trigger js code that will call someForm.submit. Still, be cause we
don't know, we have to propagate an event identifier trough all the calls until
we arrive in the form submission code. Now we cannot pass an argument from call
to call, that would require a change of pretty much every method that can be
present in a stack that ends up in the form submission code. The only way to do
this is to find out if the triggering event can be identified alredy in the
current implementation or if the event identifier can be stored in the memory
and checked when form submission is about to occur. the second option has a
catch: the form submission must be executed syncronously within the handling of
the trigerring event.

will open a bug on that and let this one be tech evangelism.  

Comment 12

[Alexandru Savulov]

new bug for double form submission prevention improvment:

http://bugzilla.mozilla.org/show_bug.cgi?id=161990

Comment 13

[Alexandru Savulov]

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

Comment 14

[Bob Clary [:bc] (inactive)]

tech evang june 2003 reorg

Comment 15

[Max Kanat-Alexander]

Seems FIXED to me, Win2K Mozilla 1.3 Final.

Seems to have been fixed by bug 138957.

-M