Closed Bug 102407 Opened 23 years ago Closed 22 years ago

Unexpected instances of POSTDATA warning messages [form sub]

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: wkfx2003-bugzilla, Assigned: shanjian)

References

(
URL
)

Details

(Keywords: topembed+, Whiteboard: [adt2 RTM] [06/12])

Attachments

(1 file, 2 obsolete files)

patch, rewrite method string comparision
3.36 KB, patch
shanjian
: review+
darin.moz
: superreview+
jud
: approval+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4+)
Gecko/20010928
BuildID:    2001092803

"The page you are trying to view contains POSTDATA. If you resend the data, any
action the form carried out (such as a search or online purchase) will be
repeated. To resend the data, click Ok. Otherwise, click Cancel." always pop-up.
Is there any way to disable it after I see it the first time?

Reproducible: Always
Steps to Reproduce:
1. Open an email account
2. Send yourself an email
3. Try to read the mail


Actual Results:  The message warning disappear everytime you click the message
subject.

Expected Results:  Provide method to ignore such warning on per session basis,
or per site basis
Yes...this warning comes with nearly every form. Much more often than with
netscape 4.x

No dupes found. Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPEME
*** Bug 104329 has been marked as a duplicate of this bug. ***
And it seems there are two versions of such dialog, saying similar thing with
minor word difference.

PS1
In recent build, I visit the same site and I can see
<html><body></body></html> when the page seems to reload / POST form by itself
(JavaScript?) and such POSTDATA warning appear frequently that cause the page
reload and reload. I used Netscape4.x and IE5/6 has no such problem.

The problem is not just the warning.

Hitting "back" should never need to cause a new copy to be 
retrieved, so it should never be necessary to repost form 
data (at least not for recent pages).  This is a performance 
issue if nothing else, particularly for those of us on a dialup.  

I suspect scripts that use GET may be reloaded on back also, 
(and they should not be) but we don't see an error message
because the data is present in the URL.  I will test this 
and report back.


I may have been wrong about GET.  I wrote a script that keeps a 
number in a file and increments it each run, reporting it in the 
output, so that hitting reload increments the number in the page.  
The output also includes a link, and following the link and then 
hitting back does not change the number -- i.e., the page is not 
being reloaded.  This is with Apache, with CacheNegotiatedDocs 
_not_ turned on, so that Apache _is_ sending Pragma: no-cache.  

Then again, I can't reproduce the problem with POST at the
moment either, so either it's been fixed in recent builds,
or else I've done something different from the scripts that
exhibit the problem.  I will retest with older builds and
other scripts and see which is the case.   

I can no longer reproduce this bug at babel.altavista.com
either.  It seems to have vanished.  Will do comparisons
with earlier builds, but I think it may have been fixed
somehow without leaving NEW status.


Confirmed:  behavior changed sometime between build 2001100903
and build 2001102309.  Everyone concerned with this bug please 
retest and verify that this bug has resolved itself.  If someone 
happens to already have a build installed from between Oct 9 and 
Oct 23, it might be good to narrow down a little closer when the 
change occurred, especially since it might be a side-effect of 
some other change.  


reassigning
Assignee: rods → alexsavulov
Summary: Provide method to disable POSTDATA warning → Provide method to disable POSTDATA warning[form sub]
This warning often appears double or 3 times for one form. 
Someone told me it is caused by a slow internet connection. So 
developers attached to a fast internt will never see it!
I'm pretty sure that there is a bug!
Jens: What you're describing is bug 105636. Please try a fresh profile, as that
should solve it :). You can manage/create profiles with "mozilla.exe
-profilemanager".
setting milestone
Target Milestone: --- → Future
Priority: -- → P5
*** Bug 127456 has been marked as a duplicate of this bug. ***
I did not have this problem with mozilla 0.9.7 and 0.9.8, but I get the
dialog-box on almost every form since I installed User-Agent: Mozilla/5.0
(Windows; U; Win98; en-US; rv:0.9.9) Gecko/20020311 BuildID: 2002031104
Same for me, I did not experienced the problem with previous releases (up to
0.9.8) buth with 0.9.9 (on w2k) it happens all the time (practically with all
free e-mail and SMS services). IMHO it is awfully annoying and should be fixed
in 1.0.
Could you please provide some example sites so we can advocate getting this bug
fixed for 1.0? It seems like this has become a bug report, and is no longer an
enhancement request...

I have experienced this on http://epinions.com where 
1. I submit a form
2. They give me a server error (not easy to replicate)
3. I go Back to try to resubmit my data again. 

Result: I get the POSTDATA warning, but go back...and my form is erased :-(
Keywords: topembed
Here is one case that happens only with topembed-based builds: 

1->Enter www.brasoftware.com.br
2->Try to put any product into your shopcart by clicking on "Compre aqui" <Buy here>

Result : You'll get the following message : "The page you are trying to view
contains POSTDATA. If you resend the data, any action the form carried out (such
as a search or online purchase) will be repeated. To resend the data, click OK.
Otherwise, click Cancel. "
But the product is only added once to you shopcart.

The site that I added before in comment 17 is part of the top list of sites in
Brazil.

Additionally the MAJOR BANK in Brazil also demonstrates this problem.It's
http://www.bradesco.com.br bank and if you log on with your account (talk with
me for tests) in the bottom you will see the message. 
ok, i have this on my radar now
Priority: P5 → P3
Target Milestone: Future → mozilla1.1beta
Changed subject line from "Provide method to disable POSTDATA warning[form sub]"

Changed from P3 enhancement to P3 major
Severity: enhancement → major
Summary: Provide method to disable POSTDATA warning[form sub] → Unexpected instances of POSTDATA warning messages [form sub]
The Moz 1.0rc1/WinXP would cause me to order twice on the same item in ebuz
sites. (dxcart.com)  This bug is definitely critical.  Should be in 1.0 not suck
list.

Click OK will order twice, click cancel will blank out.
This bug happens with many sites on the Internet. E.g. with freemail.hu which is
the biggest free e-mail service provider of Hungary.
The bug did not exist until Mozilla 0.9.9 (at least I did not notice it), I do
not know what has changed.
I highly agree that mozilla 1.1 is too late for this bug, it is absolutely critical!
Keywords: nsbeta1
Keywords: nsbeta1 → nsbeta1+
Whiteboard: DUPEME → DUPEME [adt2]
This sounds like it affecting more people (and, now on top sites), so nsbeta1+/adt2
This will affect a lot of sites per evangelism.
Whiteboard: DUPEME [adt2] → DUPEME [adt1 RTM]
I stepped thro'  docshell to see if anything strange was happening in the 
recent builds. I didn't see anything unusual or unnecessary invocations of the
dialog. The postdata dialog usually thrown whenever,

1) A postdata result has expired out of cache and the user seeks to go to it
through back/forward/go menu.
2) Reload is done on a postdata result. 

I created a new userid in kamfung.net and sent a mail to myself.  The dialogs
came up more often  during the first session when I created a account for myself
and sent myself a mail rather than in my second attempt when I already had an
account and just sent mail to myself. During my second attempt, the dialog came
up only for the the page I get after I do, "send message". The dialog did not
come up when I wanted to view one of my mails in the inbox or try to go
back/forward to the INBOX.  In all these cases, the dialog was thrown in
nsWebShell::EndPageLoad() when it realises that a page that was originally 
requested to be loaded *only* from cache was no longer available in cache and
therefore docshell needed user's permission to go out to the server and resubmit
the data.  

I looked through all the changes went in to nsDocShell.cpp and nsWebShell.cpp
during the month of October 2001. There were no significant changes to
nsWebShell.cpp. In nsDocShell.cpp, I had fixed few bugs w.r.t expired frames. It
is possible that kamfung.net and the banking site are using either expired
pages/frames  in combination with cache-control: no-cache for all form submits.

However, I would like a good testcase  that shows the unwarranted display of the
dialog.
Darin, Which cache control flags or situations in necko trigger the error code 
NS_ERROR_DOCUMENT_NOT_CACHED to be sent to OnStateChange()? Could any recent
change in cache/necko trigger a page to be marked expired from cache even though
it is not?
radha: that error message is only generated when a consumer calls
nsICachingChannel::SetCacheKey(key, PR_TRUE) on a http channel and the cache
entry does not exist.  i've actually seen this error occur several times when
posting messages to bugzilla bugs.  it seems to happen more often when i change
my window focus before the form submission completes, which is really really odd.
radha:

if you think is not form submission please take it. i have another important
nsbeta1+ before i can get to this one. thx!
Taking from Alex Savulov to take a closer look.
Assignee: alexsavulov → radha
Status: NEW → ASSIGNED
Target Milestone: mozilla1.1beta → mozilla1.0
Folks, 

New information that could be related and maybe it's very important. 

If you turn auto-detect on, you will see many more cases of this problem. After
turning on, enter the following URL and click the button [compre aqui] in the
right side. 

Enter http://www.brasoftware.com.br/descricao.asp?codprod=CE0719 click [compre
aqui]. 

All the products based in Mozilla with auto-detect on are displaying this
problem much more. 
Another one: submiting this bugzilla form with auto-detect on causes the problem ;)
I'm using mozilla rc1 linux.

By enabling auto-detect for the korean character coding, the POSTDATA problem
occurs with the bug URL: http://webmail.kamfung.net

By enabling auto-detect = off, the problem does not occur.

(view -> Character Coding -> Auto-Detect)
Roger: You're seeing bug 105636, which was marked as a dupe of bug 116217, which
was marked as a dupe of bug 61363. 

PS If you're going to post to a bug, please add yourself to the CC list --
otherwise, you won't receive any of the responses ;).
sounds like a duplicate of the meta charset reload bug.

*** This bug has been marked as a duplicate of 61363 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Though the  root cause behind this bug might be bug 61363,  there are other
checkins that have also contributed to the dialogs showing up so often on pages
with meta charset. These are

1) Fix for bug 89309 made on Sep 26, 2001. That bug says, "Normal Reload on a
postdata result should always bring up the dialog to take user's permission to
send the data to server.". This bug was fixed for compatibility with NS 4.x. 
Though this argument holds good for reloads on a regular postdata result, it
does not work well when we reload due to charset detection. The changes for this
bug were in nsDocShell::LoadHistoryEntry() which simply took user's permission
to resend post data to server. It is not clear to me of the
LOAD_RELOAD_CHARSET_CHANGE was invented then. 

2) Code in
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#4872 which
passes the PR_TRUE flag to SetCacheKey() when the load type is
LOAD_RELOAD_CHARSET_CHANGE. When PR_TRUE is passed  to SetCacheKey(), we are
essentially asking the page to load only from cache. When loadType is
LOAD_RELOAD_CHARSET_CHANGE, we are in the process of actually loading the page.
Cache may not have the whole page in it or not yet closed its connections etc...
But we ask to load the page *only* from cache, so we get a second dialog from
nsWebShell::EndPageLoad() that says, the page you have requested has expired
from cache. So, to fetch it from server, click OK. ...". While that part of code
has gone through 2-3 rounds of changes, it is not exactly clear to me  when and
why we decided to use the SetCacheKey(key, PR_TRUE) when loadType is
LOAD_RELOAD_CHARSET_CHANGE. I'm sure there was some other intl related issue
with it. 

These 2 contribute to the unwarranted show of the dialogs. While the effect
caused by 1) can be fixed, I'm not sure of 2). I have to play around and talk to
some intl folks about why we need this flag when the loadType is
LOAD_RELOAD_CHARSET_CHANGE. 

I'm not confident that bug 61363 will make it to mozilla1.0. But this bug can be
taken care to a reasonable extent. Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
cc'ing ftang, 

please read my previous comment and provide your input on why we should always
fetch pages  *only* from cache when the load type is LOAD_RELOAD_CHARSET_CHANGE.
Status: REOPENED → ASSIGNED
topembed+.  Susie indicated to me that she has tested this bug and can repro
using the latest embedding client.
Keywords: topembed → topembed+
radha: we must reload from cache because otherwise we'd have to reload from the
server which would mean duplicating a form submission, and we can't do that. 
but, because of the problems you pointed out, loading from cache is not an
option either.  that's the reason why the only solution to this bug is to fix
bug 61363.

LOAD_RELOAD_CHARSET_CHANGE is a terrible awful hack that should be eliminated.
If anyone wants an easy real world test case, I just discovered that Craigslist
 relies on the Back button for editing classified listings. You get the Postdata
message and erased form. http://www.craigslist.org/cgi-bin/formProcessor.pl
Darin, Can anything be done about the situation where the page is not yet
officially in cache and docshell requests the page to load from cache and
therefore we end up getting the second type of dialog in
nsWebShell::EndPageLoad().  I can modify nsDocShell::LoadHistoryentry() so that
we don't throw the first dialog when loadType is LOAD_RELOAD_CHARSET_CHANGE. 
Susie, I can not reproduce the problem with www.craigslist.com in the trunk
mozilla  builds. With or without setting the charset detection.
Attached patch patch v 1.0 (obsolete) — — Splinter Review 
Partial patch to the problem. This patch prevents the appearance of the first
postdata warning. Basically issue #1 described in my comments above is taken
care by this patch. You *may* still get the dialog that says that the "page has
expired from cache. Click OK to get it from server", depending on whether the
page is available in cache or not. As Darin mentioned, fixing bug 61363 is
probably the only way out to completely take care of this problem.
This bug is like bringing your car to the mechanic: It only happens at the worst
time, when you really don't want it to happen, when no one else is around to see
it. 
radha: so with your patch the user would just see a blank page?  or what?
radha: the only thing that can be done to solve this bug is to fix bug 61363.  i
see no other way around this problem.  we should focus on solving that bug
instead of this one, although i agree that your patch is probably a good one
from the point of view of not confusing the user as much.
Darin, my patch just brings down the number of dialogs that show up from 2 to 1.
OS: Windows 2000 → All
Who's gonna review this one? If you want to champion this one for MachV, you are
gonna the patched reviwed and a= by tomorrow.
Blocks: 143047
The bug that this one depends on bug 61363  has been targeted for mozilla
1.1alpha.  In that case, I have to move this one out too.
ok, i can reproduce this bug 100% of the time if:

1) open multiple tabs
2) make a comment in a bugzilla bug
3) before the comments have been submitted, switch to another tab
4) notice the POSTDATA dialog

seems 100% reproducible to me.  also seems to happen whenever i switch focus...
tabs just seem like a convenient way to steal focus from one browser window. 
clicking on another application window also seems to _always_ do the trick.
Other test case to get this dialog:

Go to a form. For instance, this very add-comments form in bugzilla. 

Work offline.

Put something in the comment box.

Hit "commit". Instead of complaining about being offline, complains about
POSTDATA. Wrong!
Whiteboard: DUPEME [adt1 RTM] → DUPEME [adt1 RTM] [Need ETA]
This bug depends on 61363 which has moved ti mozilla 1.0.1. I'm moving this to
1.0.1. This can not go into Macb V unless 61363 is fixed.
Target Milestone: mozilla1.0 → mozilla1.0.1
Radha, are you saying this bug is less important because 61363 was rated less
important?  That doesn't make immediate sense to me unless this is really an
exact dup of 61363.  I would have expected that this bug being ADT1 RTM would
have raised the importance of 61363.

Can anyone from the ADT jump in here?
This  bug is almost a dupe of 61363.  Once 61363 is fixed, my job is to remove
some code from docshell that was put in as a bandage. I can not fix this unless
61363 is fixed. It would be great if 61363 is fixed for RTM. 
This  bug is almost a dupe of 61363.  Once 61363 is fixed, my job is to remove
some code from docshell that was put in as a bandage. I can not fix this unless
61363 is fixed. It would be great if 61363 is fixed for RTM. 
Changing impact from [ADT1 RTM], to [ADT2 RTM], as this depends on bug 61363,
which  has an impact of [ADT2 RTM].
Whiteboard: DUPEME [adt1 RTM] [Need ETA] → DUPEME [adt2 RTM] [Need ETA]
Another example of a broken site.
I'm sure people from North America are familiar with a company called
Blockbuster. So here it goes (WHEN THE SITE WORKS):

(Character Coding is set to Unicode (UTF-8); Auto-Detect is set to Russian)

1. Go to http://www.blockbuster.com/
2. At the top of the page, there's place to search for a movie. Let's search for
"Zoo". I get two warning "POSTDATA" dialogs right after.
3. Continue on. Select first search result ("ZOO-OPOLIC!").
4. Select Store Search in the middle of the page.
5. Type San Jose, California. Continue. Two more warning dialogs.
6. Select 1st location available. Press the button "choose this one>". Another
two or three warnings appear.
7. Try to go back (Back navigation button). I get two (or three) more warning
dialogs and return to the same page. Ability to go back is lost!

Obviously, code behind the site is not of the best quality, but that's besides
the point. The site works in NS4.7x as expected.

reassign this  bug to myself. I am going to use this bug to handle this problem
and leave 61363 open for future complete fix.

Jaime wrote in bug 61363:
A short term solution that we're considering is:
1) The default charset for a page should be set to the charset of the referrer
(both in the link and the form submission case). This is dealt with by bug 143579.
2) Auto-detection should not happen when there's POST data associated with a page. 

Some pages may not be rendered correctly, but this solution should deal with the
common case.
Assignee: radha → shanjian
Status: ASSIGNED → NEW
Attached patch patch (include patch for 143579) (obsolete) — — Splinter Review 

        Attachment #81569 -
        Attachment is obsolete: true

    
  
No longer depends on: latemeta

    
    

    
  
ftang, could you review? 
Blocks: 141008
Status: NEW → ASSIGNED

    
  
Keywords: mozilla1.0.1
Whiteboard: DUPEME [adt2 RTM] [Need ETA] → [adt2 RTM] [06/07]

    
    

    
  
are we suer the "POST" is always upper case in !methodStr.Equals("POST"?
should we do case insensitve comparision. the rest look right.


    
    

    
  
Comment on attachment 86753 [details] [diff] [review]
patch (include patch for 143579)

r=ftang except the case of POST issue.

        Attachment #86753 -
        Flags: review+

    
    

    
  


  

        Attachment #86753 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 86838 [details] [diff] [review]
patch, rewrite method string comparision

carry over review

        Attachment #86838 -
        Flags: review+

    
    

    
  
rick, could you take a look at my patch and sr=?



    
  
Keywords: approval
Whiteboard: [adt2 RTM] [06/07] → [adt2 RTM] [06/10]

    
    

    
  
Shanjian, Could you please explain the effect of your patch w.r.t to the
Postdata warning dialogs? Does your patch prevent the reload that is triggered
on the docshell when a new charset is detected? What exactly happens to such
documents with Postdata on them?  Could you also explain the effect of your 
patch on the url provided here. Also, Please take a look at Bugscape bug 14778
which has more testcases. 

mgalli, susiew, You both have contacted me in the past about this bug and
probably have more testcases for this bug. Can you try the patch attached here
and post an update.  Thanks.

    
    

    
  
The default charset is being set as previous document. By swapping the order of
default charset and weakDoctype charset, we are using previous charset to load
the document. That is the charset of the document which submit the post. For
"POST" document, we also disabled autodetector, and thus there should be not
reload request triggered by charset auto detector. To summarize, this patch is
basiclly always charset of submitter document to load submittee document. 

What this patch could not handle:
The charset of sumbitter doc is different from the charset of submittee, AND
submittee does not have meta charset with first 2K of data. As we discussed
yesterday, that rarely happen and we don't want to address such situation at
this time. 

    
    

    
  
I'm a little disappointed with the arbitrary 2K limit and displaying of content
in incorrect charset. Why cannot you keep loading the document to the end even
though meta charset says it's in another charset and after the document has
finished, reload the document from the cache in the same way as viewing source
(finally!) works. Or is cache storing documents only after the charset encoding
has been interpreted? I hope not. The performace could degrade but at least
Mozilla would be doing the right thing. Performance can be increased later if
really seen important (how often charset is changed during POST anyway?).

Hopefully the issue gets fixed for GET too (is there another bug for it
already?). I see no real reason to reload any document twice from the server
just because charset has been changed.

I put up a little test at http://www.cc.jyu.fi/~mira/moz/moztest.php which uses
cookies to save 7 last page loading times and changes charset every now and
then. And sends meta charset after 2K. Automatic reloading can be seen as
subsecond reload times and flashing on browser view.


    
    

    
  
Mikko Rantalainen, 
You can put your further comment about this problme in 61363. This bug is meant
to offer a very low risk fix. That's the only way it can get into branch.

    
    

    
  
Could any super reviewers give a sr? rpotts? darin? vidur?

    
    

    
  
Comment on attachment 86838 [details] [diff] [review]
patch, rewrite method string comparision

>Index: nsHTMLDocument.cpp

>+  if(kCharsetFromAutoDetection > charsetSource) {
>+    nsCAutoString methodStr;
>+    if (httpChannel) {
>+      rv = httpChannel->GetRequestMethod(methodStr);
>+      if (NS_FAILED(rv) || !methodStr.Equals(NS_LITERAL_CSTRING("POST"),
>+                                             nsCaseInsensitiveCStringComparator())) {

you don't need a case insensitive compare here.  assume uppercase.  i'm
assuming
we don't have to worry about HTTP PUT (used by editor's publish feature) in
this
context.  am i correct?

with this change, sr=darin

        Attachment #86838 -
        Flags: superreview+

    
  
Keywords: adt1.0.1
Whiteboard: [adt2 RTM] [06/10] → [adt2 RTM] [06/12]

    
    

    
  
POST is the only thing I worried about for now. I will remove case insensitive
comparison. 

    
    

    
  
As requested by Jaime, I made a local build and post it to 
jazz/users/shanjian/publish, bin.zip. QA, could you download it and give it a
try? thanks.

    
    

    
  
vladimire - please could you verify this bug is fixed in the test build, and 
check the surrounding areas for regressions.

    
    

    
  
I think this is ADT1 instead of ADT2. Leave adt team to change it. 

    
    

    
  
fix checked into trunk. 
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED

    
    

    
  
It is fixed on the test build.

    
    

    
  
Verifying on the trunk 2002-06-12-08-trunk on windows 98 and RedHat Linux.
Status: RESOLVED → VERIFIED

    
    

    
  
adding adt1.0.1+.  Please get drivers approval before checking into the branch.
Keywords: adt1.0.1 → adt1.0.1+

    
    

    
  
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+

    
  

        Attachment #86838 -
        Flags: approval+

    
    

    
  
checked into branch.
Keywords: mozilla1.0.1+ → fixed1.0.1

    
    

    
  
vladimire - pls verify the fix on the 1.0 branch, then replace "fixed1.0.1" with
"verified1.0.1". thanks!

    
    

    
  
verified on branch
Keywords: fixed1.0.1 → verified1.0.1

    
    

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

    
  
Blocks: 146292
No longer blocks: 141008
Component: HTML: Form Submission → DOM: Core & HTML

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: