Open Bug 49864 Opened 25 years ago Updated 3 years ago

'submitting insecure info' popup inconsistent

Categories

(Core :: Security, defect, P3)

x86
Linux
defect

Tracking

()

Future

People

(Reporter: mike+mozilla, Unassigned)

References

()

Details

(Please reassign and recategorize if the belongs somewhere else. You were mstoltz's guess as to the appropriate owner.) At http://maps.mcom.com/ (and probably any other form submit site) typing something into the locator bar and pressing enter brings up a popup dialog: 'Security Warning: any information you submit is insecure etc.' However, typing something into the locator bar and then clicking elsewhere on the page *still* performs the search, but doesn't bring up the popup.
I don't think necko throws the security dialogs. my best guess would be docshell/uriloader area. ->rpotts and cc'ing mscott.
Assignee: gagan → rpotts
QA Contact: czhang → junruh
Qa > ckritzer
QA Contact: junruh → ckritzer
Target Milestone: --- → mozilla0.9.2
-> chak. maybe thayes should look at this?
Assignee: rpotts → chak
->thayes Hi Terry : Please let me know if you're not the right person to own this...Thanks
Assignee: chak → thayes
This site doesn't actually submit a form to load the content in the lower frame. Instead, some Javascript changes the location URL of the lower frame according to the data in the text box. This action is in response to an "onchange" handler, which seems to get fired when you click outside the text box, or hit ENTER. In addition, the ENTER key seems to also cause form submit processing, which generates the warning box, even though there is no POST happening, and there isn't a URL to POST to. -> rpotts Should the form submit fire in this case? If so, can the listener tell that it's not really being sent anywhere?
Assignee: thayes → rpotts
retargeting to mozilla 1.0
Target Milestone: mozilla0.9.2 → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
retargeting
Target Milestone: mozilla1.0.1 → Future
With an IE client, this does not happen. ie. no warning is displayed. However, with the Netscape client, it appears to be the default behavior. It seems that this behavior cannot be avoided in Netscape when running over the internet when one submits form data to a cgi script. Actually, I was able to avoid this behavior in Netscape 6.0, over SSL, by unchecking the box "Leaving a site that supports encryption" under Tasks|Privacy & security|security manager|applications|Leaving a site... The latest Netscape download (7.2) did not have this setting available, but a similar one that reads Leaving a page... This didn't work to remove the Security Warning for 7.2. So, in this respect, not having the ability to remove this warning, maybe a step backwards in 7.2 version. Referenced behavior: "Security Warning window: Any information you submit is insecure and could be observed by a third party while in transit... " More detail: When I het "enter" on a search box, the <form> submits and invokes the action item which is a reference to javascript:function. To get around having to submit the form, I put an onKeyDown call in for the text area. It appears that the onKeyDown triggers and runs the javascript with no problem/warning message. Then, the form does a double take, and invokes the action item in the <form> tag. What's weird is that same function call is used on invokation of onKeyDown trap where key==13 (enter key) as that called out in the action item for the form tag, even if I specifiy a different javascript function for the onKeyDown trap. The apache log shows two identical invokations of the same GET call (found in the javascript function). I have to assume is happening as a result of the <form> submition/action item, and that the function called out in the onKeyDown trap on the text area is simply not getting parsed out of the form by the client - it's being replaced by the function call in the action item. Yet only the function call in the action item - made during the <form> submit - is causing the Security Warning window to come up. Yes, strange but true. Can someone duplicate this please? Or give me a clue, cause I ain't got one. Hope that's a proper contraction.
Assignee: rpotts → nobody
QA Contact: ckritzer → toolkit
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.