Closed Bug 45666 Opened 24 years ago Closed 24 years ago

Mozilla using previously cached page while looking at bugzilla

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: mcchambers, Assigned: asa)

Details

I'm not sure which component this should go to, so please reassign if I get it
wrong ;c)

Mozilla seems to like using previously cached webpages over the newly
representing page. Here's what I did. (Query paged left as defaults with the
exception that all the statuses on both queries (uncomfirmed, resolved, etc.)

1) Went to bugzilla query page and queried URL: woot.net
2) Viewed all bugs in query (last, first, next)
3) Clicked on Query
4) Viewed all bugs in query Email: hoserhead@bigfoot.com (reporter)
5) Started viewing all the bugs in order

I'm on bug 15 of 27, until I clicked next. No problem, the next page shows up
with the exception that its bug 1 of 3 from my previous query. The expected
result should be bug 16 of 27 of my current query.

I haven't test this for reoccurence yet, I just thought I report the bug now
before I forgot what happened :> but I will test it for reoccurence!
This bug is reproducable (for me at least)
Jason, are you performing a second query in a different window?  This can
replace the buglist with a list from the new query.
Same browser window.
OK, I followed your steps exactly.  query one, view first bug, hit next to view 
second bug hit next to view third bug hit Query Page to do query two.  query 
two, view first bug, hit next to view second bug, hit next all the way down the 
list.  I get through to the 27th bug in the list just fine.  Tested with 072008 
mozilla bits on NT.  Can you delete your mozilla installation and try this again 
with a current build.  Is it always on number 15 that it jumps to the other 
list?
Actually, with the first query it was the last bug, the first bug, then the next
bug (3,1,2) but I'll verify with todays build (20000720)
This bug is not present in todays build, but yes it was always the from the 15th
bug it would jump into my first query. Marking as RESOLVED WORKSFORME. I'll do
more test cases on this bug in future builds just incase it crops up again.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
cool.  glad it cleared up.

Reopening bug due to same problem in build 20000725, Must be a regressing
regression bug if that makes any sense! Should we mark this a regression or not?
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
no need to mark it as regression.  I, however, still cannot reproduce.  adding
qawanted keyword for help.
Keywords: qawanted
i'm not seeing this at all w/ 2000072508 on w2k
I should state that i'm not going from a page of queries, to a bug, then
clicking back to a page of queries. I'm always Clicking on the Next link. I
dunno, maybe it wants to act this way sometimes, and other times it'll act
normally. I just reproduced this bug again using the same build 20000725. This
is definantly puzzling.
and you can't reproduce this in navigator? (possibly a bug in bugzilla and not
mozilla?)
Tried, but can't... but I'll keep trying!
confirming using 2000072508 on w2k. i just it saw after reading Jason's post
after mine, i must have done something wrong the first time i tried, sorry
Status: UNCONFIRMED → NEW
Ever confirmed: true
At least I'm not alone on this one :>

I don't believe this is a bug case on bugzilla's behalf, unless for some reason
it caches previous queries on its website. The other reason is that when it
jumps from a bug from my second query, to a bug in my first query, it doesn't
take as long to load the page (My guess because it found a simular page in its
cache)
At the risk of confusing this bug, I think it's a bugzilla bug [not mozilla].  
I think I experience these sorts of issues with both nc4.73 and ie5.5

Reporter, if you can possibly take your questionable builds and run windows9x 
or nt4 from the same computer [as well as trying with netscape4 and ie].

Does anyone experience this on an os other than 2000?

Other questions which occasionally are relevant: Are you on dialup? does your 
ip change? what's your connection speed?

I never had such problems while I was on a non changing dhcp ethernet network, 
but now I'm on dialup (avg 26.4) ppp [persistent ip]
I am not attempting to install a second os on my computer.... and the chances of
me getting at another computer to run mozilla is nil. The attempt to reproduce
the bug in 4.73 hasn't happened yet. (Only 4 test cases) I haven't yet tested
ie5.5. And I don't see the relavence of connection being a problem? What would
chance if your connection to the internet is different (To the browser that is)
instead of speed differences.... But I am on Rogers@Home cable (static ip)
I am still unable to reproduce this bug.  I've tried on NT, 98 and Mac OS9 and I
cannot get it to display the buggy behavior.
!!! WTF !!! Okay, does this bug like to be a ghost or something? AFAICS, this
bug will pop-up in only certain builds...  (20000717, 20000725) yet not on
others (20000720, 20000804) and so far only people have been able to reproduce
this on win2k. But it could be possible that this bug might appear only some of
the time and not always. Steven Walker couldn't get the bug to crop the first
time he did the queries, but he said he was able to reproduce this bug the
second time after he reread everything.

Just to make sure that we have the same query results, I click the first query
in this order: bug 1782, bug 2008, bug 1326. (3of3,1of3,2of3) In the second
query I get this order: bug 2003, bug 2004, bug 2008 (14of27, 15of27, 16of27 but
sometimes pops up as 1of3)

This bug might not be seen on NT bits (4 or under) but it is reproducable in
win2k (i have pro, what is steven walker using?)

Now i am questioning that since strict DTD has been disabled, that this bug not
reproduce.. I know it might be unrelated, but there might be a fluke somewhere
that could make it related! :/

Comments?

Cannot reproduce on 2000080520 (what the? whats the diff between 08 and 20?? is
that the hours they were compiled at?)
Still not reproducable in 2000080608
since strict DTD has been disabled?  Where did you see that?
bug 42388
(sorry for spamming this bug again) Jason, that bug was about disabling the
Transitional DTD, not the Strict DTD. 
marking this worksforme.  reopen if it happens again.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Could at least be related is some manner?

I don't think i'm going to be downloading nightlies for awhile, going to use
N6PR2 for probably 2 weeks before I get a nightly :/
I've seen this often on win95, reopening
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
don't reopen unless its a recent build!
Resolving bug again, because of ones stupidity
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Lets make this bug verified since this bug hasn't cropped up for a long while.
And hopefully it wont appear again.
Status: RESOLVED → VERIFIED
Keywords: qawanted
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.