Closed Bug 82749 Opened 23 years ago Closed 22 years ago

chrome:// uri's load three times

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: bugs4hj, Assigned: trudelle)

Details

(Keywords: helpwanted, perf, qawanted, Whiteboard: [nav+perf][br]) 

Tested on build 2001051208 and later on WinNT4

1 - type 'about:cache' into the urlbar
2 - click on 'List Cache Entries' (Memory cache device)
3 - note the 'Fetch count' for chrome uri's
4 - open new window (Ctrl-N)
5 - repeat step 1,2,3

Now what did you notice, loading all chrome:// uri's three time, right? So why
is this loadfacter 3?? Even from cache, can't be a big help for opening a new
window does it?
changed component after a chat on #mozilla with asa
Component: Browser-General → XP Apps
reasign.
Assignee: asa → pchen
QA Contact: doronr → sairuh
Status: UNCONFIRMED → NEW
Ever confirmed: true
Adding perf keyword.
Keywords: perf
nav triage team:

Needs investigation. Marking nsbeta1+, p2, and mozilla0.9.3. Also cc-ing hyatt.
Keywords: nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
Whiteboard: [nav+perf][br]
nav triage team:

Although nice to fix, not a mozilla0.9.3 stopper. Pushing out to mozilla1.0
Target Milestone: mozilla0.9.3 → mozilla1.0
I'm not convinced this is a real bug anyway.

> I'm not convinced this is a real bug anyway.

Hyatt, can you please explain your comment? Should it load chrome uri's three
times? Is there a reason for this? It's not very clear to us why 'it' loads
chrome uri's three time, or is it? It seems to me that I'm not the only only one!
I'm just saying that if all chrome URLs were really loading 3 times, then
performance would be about 10 times worse than it is now, so it's got to be a
mis-reporting of some kind.
Target Milestone: mozilla1.0 → Future
->hyatt
-> default assignee
Assignee: pchen → trudelle
Target Milestone: Future → ---
This should either be resolved as invalid or fixed, but since Hyatt sez it
tain't possible, ->future/helpwanted.
Keywords: helpwanted
Target Milestone: --- → Future
Looks for me like bug 85614. Nevertheless it's a confusing "fetch count" info.
Keywords: qawanted
QA Contact: sairuh → nobody
I can't even reproduce the originally reported problem. WFM.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
"I can't even reproduce the originally reported problem. WFM."

Hehe, that's only because this bug was reported with build 2001051208! and
that's what? 7 months later? Go figure...
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.