- Searched for book at amazon.com - backed up through selections - While backing up through several pages, I ended up with the following message: "Browser Bug? It would appear that the web browser you are using, Mozilla/4.05 [en] (Win95; I), does not know how to re-submit forms correctly when you try to reload a page. If you want to reload the page you were on, try using your browser's BACK button or command to go back to the previous page, and resubmit the form yourself, instead of using RELOAD." I was not using reload, but was in fact using the back button.

I just checked with nglayout and verified this bug. Strange that our User Agent is telling sites we are 4.05, eh? Gagan & Raman, this sounds like it might be a netlib or cache bug - is this the case? If not, can you give me any pointers on it? thanks

Looks like a good candidate for post_data test in Netlib.

Setting all current Open/Normal to M4.

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

Marking till Necko lands...

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Pl. verify with Necko. If the search is doing some posting then this may not work till Posting in Necko is up and running.

this can not be tested until posting exists. Will mark resolved then try to verify when posting is available.

actually, I don't think that this can be verified until we have a working cache

Re-opening as this is still occuring. This may be a duplicate of another bug, but I'm not sure if this is cache or what. Fur? To duplicate: 1. Goto www.amazon.com 2. Under search, put in 'furman' and click go 3. Click on the elina furman link 4. Hit the back button Results: You will get the error message that says your browser doesn't know how to resubmit forms when loading a page. Marking Dogfood as this happens on lots if not all pages with form submission results (like search pages).

Re-submission of form data to the server during back/forward is related to session history, not cache. Sounds like this is a dup of 8241 or vice-versa.

Okay, I made 12651 dependent on this bug, and gave back to raman. I will leave it as DOGFOOD and see what the PDT gods say.

Putting on PDT+ radar.

removing M10 TFV

removing NECKO from summary, that's default now.

raman doesn't work here anymore. Since fur suggested that this is a possible dup for 8241, I'll reassign this to the owner of that bug.

Added dependency on Webshell work, bug #13374. Can we get this completed enough for dogfood before 12/17?

I need to be able to get/set Post data from webshell to fix this. That will not happen in the existing webshell. I have to wait until new docshell to fix this.

Need redesigned webshell to fix this.

Is this bug a dup of other history bugs? Do you know when the piece of webshell you need is landing?

Moving to M13.

This is dependant on some other History bugs but not a dup of any AFAIK. Early next week is what I hear Travis.

Removing PDT+ status because it's obvious we're not gonna hold up dogfood for this.

Putting on PDT- radar. spoke with don, enough of this is working at this time.

PDT asked me to check this out, it still occurs with 12/15 M12 candidate builds. To duplicate just go to amazon.com, click on books, search on Orson Scott Card, click on Ender's Shadow, and press back button. You will get the error. To me this is borderline PDT+. It is a bit annoying. setting claudius as qa contact

Re-summarized.

This s'd be fixed automatically when 17685 is fixed. I haven't marked this as a dup of 17685 because there seem to be some good info on both. In essence, when 17685 is fixed, this could be marked as fixed.

Moving all to M14 (for webshell changes that are being deferred till M14 rather than destabilize M13).

Marking as beta1.

Putting on PDT+ radar for beta1.

This would be nice to fix, but it's not a beta stopper. clearing PDT+ status.

I imagine since the pdt+ was cleared but the beta1 keyword is still there and there's no minus this will just get reviewed again. Just know that this bug and bug 17685 travel together and bug 17685 has been established as PDT+. I would think this is a major annoyance in the case of a long form or a form with a large text field suitable for entering much info, like this very page.

Don, jevering would like you to see who could work on this...before you burn his car :)

Bill actually owns Radha's bugs while she's on sabbatical ...

Chriss already cleared the PDT+ once on this. Bill Law already has a number of other PDT+ bugs. There has been no activity on this bug for the past 19 days. Clearing PDT+ again

Putting on PDT- radar for beta1.

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

how can this be open when bug 17685 is verified fixed? Aren't they closely related?

Moving to M15...

Move to M16 for now ...

In light of the webshell ans SH changes I've reevaluted this bug and it still exists as originally reported in the 2000042109 builds. marking nsbeta2, assuming we've raised the bar since beta1.

Putting on [nsbeta2+] radar for beta2 fix.

Move to M18.

Fix in hand. Shall checkin once tree opens

checked in fix

VERIFIED Fixed with 2000070708 builds

mid-air collision ? / bugzilla cleanup Reopening (current State: verfied and no resolution)

fixed

verified