Closed Bug 96480 Opened 25 years ago Closed 25 years ago

we're sometimes submitting the wrong thing to bugzilla

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dbaron, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: smoketest)

Attachments

(1 file)

http log from andreas' test
112.08 KB, text/plain
Details
Twice, using today's build, I've seen changes that I submitted to bugzilla giving me very strange results, as if we were reloading a cached submission rather than submitting the new one. In the second case, I saw a report of a midair collision on a bug I commented on a few hours before after filling in my username and password since I wasn't logged in on the show_bug.cgi page. (I was commenting on bug 96413 -- I saw the midair collision report for bug 96367.) Akkana mentioned similar problems on IRC. (all times EDT = GMT-0400): [13:19:11] <akk> Wow. I just added a comment (with today's build) to bug 96133, and apparently what it actually did was make 96094 a dup of 88458! [13:20:03] <Pike> akk: that's a cool build. Let's shove 0.9.4 out the door [13:20:05] <akk> No, that's just what it said it did. Actually it didn't do anything. [13:20:15] <akk> Just lost my comment completely. [13:20:33] <dbaron> cache problem? [13:22:09] <akk> dbaron: Yep, there's a cache problem. On the second try, it did submit the comment, but I can't see it unless I shift-reload
This probably needs to be a smoketest blocker, at least until we can tell whether it can corrupt bugzilla or not.
Severity: normal → blocker
Keywords: smoketest
And, FWIW, when I added the comment above and clicked on the "Go back to bug #96480", I had to shift-reload to see the change show up.
David: I've seen the very same thing (need of shift-reload) on today CVS build (WindowsME)
Darin, any changes to HTTP recently?
Add another "me too" to this bugger. I've had to rely on shift-reload for the past 2 days... but assumed it was something I was doing to cause it. I'm currently using build 20010822 on Windows2000 I believe this is a dup of bug 96450, but this report contains a little more info, so bug 96450 should probably be filed as a dup of this one. (if you agree, please make the necessary changes)
Sorry.. keep forgetting to add to CC.. (sorry for spam everyone) more comments: About half of the time, the 'reload' button on Mozilla will 'pretend' to reload, but it actually shows old data. Take a look at the date recorded at the top of bug lists. In many cases, reloading the page does NOT change the date (and the old data remains). Using shift-reload will indeed update the page to the correct date and update the content. This has also happened on other sites outside of Mozilla. Using my web-based email, I noticed for the first time today messages I deleted this morning re-appeared this afternoon. A 'shift-reload' cured the problem, and properly displayed my email. As noted, I have never had such a problem until today.
i've actually encountered this behavior for some time now. but, i've never been able to consistently reproduce it (and to be honest, i wasn't quite sure if i hadn't just pressed submit twice very quickly). at any rate, i suspect there may be a flaw in the way we detect a failed POST request. normally, if we read EOF after submitting a POST request then we'll resend the request. reading EOF means that the socket was closed, so this should always be the correct thing to do. so, it sounds like there must be some error in the code which implements this. a good safety measure may be to always submit POST requests on a new connection instead of possibly reusing a keep-alive connection. this would minimize the chances of a prematurely closed connection.
*** Bug 96450 has been marked as a duplicate of this bug. ***
Would switching off the keep-alive be a workaround?
Using Mozilla build 2001082203 on Win 98 my cache seems to be behaving completely differently from the build on the 20th. The 20th build would reload from cache when I went Back to a bugzilla query but would rerun the query on choosing a bookmark. It appears that with today's build the opposite is true. It seems to rerun the query on Back and use a cached copy on bookmark selection. My cache is set to automatic. Don't know if this a manifestation of this same problem or whether I am just imagining things.
lowering severity o critical.
Severity: blocker → critical
if my theory is correct, then disabling http keep-alives would eliminate this problem.
Moving back to blocker after discussion with drivers. Makes working with bugzilla a guessing game ("did it really submit?" "to the right bug?"). Also affects other sites (Ryan Pertusio comment plus personal experience with fedex and clicktv) which shakes the confidence in using mozilla for any online transactions. I noticed this problem appearing in the last day or so. Looking through bonsai for changes in netwerk, the one that jumps out is the fix for 90288 ("Pragma: no-cache"). Could that have caused this problem?
Severity: critical → blocker
My changes? I don't know. Changed lately query-handling back to pre 0.9.2, if something was depending on this I think we would have some some problems with 0.9.3 in the other direction. Also changed param handling minimally, but I haven't seen any relevant param handling in bugzilla urls. I also changed the behaviour of what is done with an empty relative url. Previously we did with http://host/path/file and "" the following: http://host/path (no standard at all). Now we do http://host/path/file instead (RFC 2396), which means we go to the beginning of the current document. If at all it might be the last change, but that was some days ago ...
The query change as well as the change about "" handling were from 08/15/2001 15:29.
this is also affecting time stamped pages; my.netscape, time.com etc. old pages are being displayed instead of the most current veriosn. "Shift Reload" retrieves the current page. is this affecting the wallet's ability to remember saved data?
I can now reproduce this with: 1) show buglist from bookmark 2) choose a bug and display it 3) hit back 4) hit reload, gets buglist without new request as opposed to: 1) show buglist from bookmark 2) hit reload, gets buglist again from server I did locally backout my changes from 08-15 and it still happens.
is this a duplicate from bug #40867 or bug #55583
from the sample HTTP log it appears that the "reload" is not being translated to the correct necko load flags. notice the LOAD_FROM_CACHE flag. this causes necko to read the data from the cache. this flag should not be set in response to the "reload" button... instead docshell should be setting VALIDATE_ALWAYS. so, this looks like a docshell/session-history bug to me.
Assignee: gordon → adamlock
Component: Networking: Cache → Embedding: Docshell
QA Contact: tever → adamlock
after further investigation i've determined that this is in fact a regression from my fix for bug 95981. if you back out my patch this bug will go away. investigating a solution...
Assignee: adamlock → darin
talked with mscott about this... seems like it would be a good idea to back out my fix for bug 95981 to get this blocker cleared.
Status: NEW → ASSIGNED
Darin one idea I just had would be to modify: nsLoadGroup::SetDefaultLoadRequest if we are setting the default load request to null (i.e. removing the default load request which was what was happening in your case), we can avoid initializing mLoadFlags to LOAD_NORMAL and try leaving the load flags unmolested. I suspect it may not be the right thing but it may fix or at least mask this problem until we can bring in Rick's load group expertise.
backed out.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
scott: actually, that's exactly my patch for bug 95981 ;-)
*** Bug 97121 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: