Closed
Bug 159859
Opened 22 years ago
Closed 21 years ago
google.com - Confirmation about sending unencrypted information is displayed twice
Categories
(Tech Evangelism Graveyard :: English US, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: brbukh, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
1.72 KB,
text/html
|
Details |
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
Related to bug 158331 ?
Comment 2•22 years ago
|
||
->PSM, I think
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → 2.3
Comment 4•22 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Component: Client Library → Form Submission
Ever confirmed: true
Keywords: regression
Product: PSM → Browser
Version: 2.3 → other
Comment 5•22 years ago
|
||
reassigning to form submission
Assignee: kaie → alexsavulov
QA Contact: junruh → vladimire
Comment 6•22 years ago
|
||
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•22 years ago
|
||
to tech evangelism
Assignee: alexsavulov → susiew
Component: Form Submission → US General
Product: Browser → Tech Evangelism
QA Contact: vladimire → zach
Target Milestone: --- → Sep
Version: other → unspecified
Comment 8•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
Do you understand why this behaviour is not happening on the 1.0 branch?
Comment 11•22 years ago
|
||
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•22 years ago
|
||
new bug for double form submission prevention improvment: http://bugzilla.mozilla.org/show_bug.cgi?id=161990
Updated•22 years ago
|
Summary: Confirmation about sending unencrypted information is displayed twice → google.com - Confirmation about sending unencrypted information is displayed twice
Comment 13•22 years ago
|
||
*** Bug 184390 has been marked as a duplicate of this bug. ***
Comment 14•21 years ago
|
||
tech evang june 2003 reorg
Assignee: susiew → english-us
QA Contact: zach → english-us
Target Milestone: Sep → ---
Comment 15•21 years ago
|
||
Seems FIXED to me, Win2K Mozilla 1.3 Final. Seems to have been fixed by bug 138957. -M
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•