305959 - View Source Displays a Cached Page After Post Submit Instead of New Page

Status: RESOLVED FIXED

(Toolkit :: View Source, defect)

Description

[Christopher Kintner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050821 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050821 Firefox/1.0+

When submiting a form using post, the view source page displays a cached version
of the page instead of the new version. This doesn't not happen when submiting a
form using get. Firefox 1.06 does not suffer from this problem but DPA2 does

Reproducible: Always

Steps to Reproduce:
1. Go to http://hwwenterprises.com/firefoxbug/
2. Fill in the textbox in the post section
3. Submit the form
4. Open View Source
5. Notice that the source does not reflect the new page

Actual Results:  
The source that was shown was a cached version of the page

Expected Results:  
The source should display the correct version of the page

Comment 1

[Dave Townsend [:mossop]]

Confirming on branch and trunk:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050827
Firefox/1.0+ ID:2005082707

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050827
Firefox/1.6a1 ID:2005082706

This is pretty nasty and should be fixed for 1.5.

Comment 2

[Asa Dotzler [:asa]]

can any of you help us with a regression window on this? 

I know we've had problems with this in the past and we want to make sure that we
don't submit the form a second time but we do need the current content. Who can
look into this?

Comment 3

[Dave Townsend [:mossop]]

I'll go through some nightlies and try to narrow it down to a day this evening.

Comment 4

[Gary Elshaw]

Confirming here on the mac. OS X 10.4.2 Branch Mozilla/5.0 (Macintosh; U; PPC
Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050829 Firefox/1.0+

Comment 5

[Dave Townsend [:mossop]]

Narrowed this down to between 2005081607 and 2005081713 on trunk and 2008081613
and 2005081703 on branch. This latter suggests the checkins:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-16+13%3A30&maxdate=2005-08-17+03%3A30&cvsroot=%2Fcvsroot

Though I can't spot anything that I might expect to cause this.

Comment 6

[Scott MacGregor]

I can confirm the regression window is indeed between 08/16 and 08/17 on the
branch  by comparing the two nightly builds. Although none of the changes in
that window look at all suspicious.

Comment 7

[Scott MacGregor]

*grumble grumble* I've backed out all of the supicious changes on the trunk
between the 16th and the 17th that also made their way onto the branch but still
see the problem. Weird. 

Comment 8

[Scott MacGregor]

I wouldn't have guessed it, but it looks like Bug 289933 caused this regression.
Backing that change out makes view source work correctly for this test case.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: safe, suboptimal fix

Brendan, unless you have a better idea of how to fix this, I think we should
just limit typeof obj = function for functions, regexps, and scripts (in the
new Script() sense) for total compat with Firefox 1.0. I suspect that some code
somewhere is testing for |typeof obj == "object"| (probably as opposed to
getting "undefined") or so.

Comment 10

[Brendan Eich [:brendan]]

Comment on attachment 194401 [details] [diff] [review]
safe, suboptimal fix

Argh.  We can't change much here, can we?

>                 if ((ops == &js_ObjectOps)
>-                    ? clasp == &js_FunctionClass || clasp->call
>+                    ? (clasp->call
>+					   ? (clasp == &js_RegExpClass || clasp == &js_ScriptClass)
>+					   : clasp == &js_FunctionClass)

Indentation is all wacky here.	Fix that so extra lines underhang the
condition, same way the the outer ?: does, and r=me.

For the trunk, we should add JSCLASS_TYPE_IS_FUNCTION or some such.

>                     : ops->call != NULL) {

While you are here, the != NULL is contrary to surrounding and prevailing
style.

/be

Comment 11

[Scott MacGregor]

thanks for the quick turn around on the fix guys.

Comment 12

[Brendan Eich [:brendan]]

(In reply to comment #10)
> While you are here, the != NULL is contrary to surrounding and prevailing
> style.

Blake reminded me why I (!) wrote that that way (C ain't JS).

/be

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked in by bz on MOZILLA_1_8_BRANCH and trunk, without tabs, but I didn't
remove the != NULL since it was quieting a compiler warning.

Comment 14

[Christopher Kintner]

The testcase now works correctly in the latest hourly builds on the branch.

Thanks for the quick response.

~Chris

Comment 15

[Scott MacGregor]

FYI, this patch introduced a crash when refreshing view source. see Bug 306580
for details. Maybe this change would have benefited from some baking time on the
trunk for a few days.

Comment 16

[Scott Gifford]

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