Reload button behaves differently navigating FTP sites

VERIFIED WORKSFORME

Status

()

P3
major
VERIFIED WORKSFORME
19 years ago
18 years ago

People

(Reporter: scalkins, Assigned: radha)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
Steps to reproduce:
1) *Navigate the tree* to the seamonkey directory under Sweetlou, starting at
the top level of ftp://sweetlou/  (Do not go directly to the URL in the URL
field above)
2)Hit the Reload button

Expected results: The Seamonkey page is refreshed at:
ftp://sweetlou/products/client/seamonkey/
Actual results: You are kicked back to the top level of ftp://sweetlou
(Reporter)

Comment 1

19 years ago
Found on Build 1999-11-23-08 M12 Linux and Mac

Updated

19 years ago
Assignee: leger → gagan
Component: Browser-General → Networking-Core
QA Contact: leger → tever

Comment 2

19 years ago
Setting qa contact/component.

Comment 3

19 years ago
*** Bug 20451 has been marked as a duplicate of this bug. ***

Updated

19 years ago
Assignee: gagan → valeski
(Reporter)

Updated

19 years ago
OS: Windows NT → All
(Reporter)

Comment 4

19 years ago
Also saw this on win build 1999-12-02-11 M12

Comment 5

19 years ago
Mass move of all bugs without target milestones to M13.

Comment 6

19 years ago
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.

Comment 7

19 years ago
this is a problem with our embedded dir listing document. cc'ing waterson and
don.

Updated

19 years ago
Assignee: valeski → don
Target Milestone: M13 → M15

Comment 8

19 years ago
Over to don.

Comment 9

19 years ago
Move to M16 for now ...
Target Milestone: M15 → M16
Bug 20451 is not a dup of this bug, but of bug 19337.

I have noticed something similar with the back and forward arrow, both with
file:// and ftp:// urls.

Expected behaviour:
Directories are treated like webpages. They show up in your history and you can
navigate between them using back and forward arrows after initial browsing

Actual behaviour:
They get ignored or overwritten.

To reproduce:
- Launch mozilla.
- Go to some directory (file:/// for example)
- Go down a directory level by clicking on the directory's name
! Try to press the back arrow to go up a level :-)
- Enter your favorite website (or a completely different directory) in the
location bar
- Now go to file:/// again by typing it in the location bar
- Go down a directory level again
! Press the navigate back button and notice you go to your favorite website
(expected: back up a level)
- Press the navigate forward button, you will be in the previous directory
- Navigate towards a picture file and view it
! Navigate back, you will be at your favorite website (Expected: the directory
containing the picture)
! Navigate forward, and you'll see the picture again (Expected: the directory
containing the picture)

Note: when doing the last few steps with text files (.txt, .java) instead of
pictures, the last step will take you to the directory containing the text file
(but you can't take one more step forward to view the text file again).

To summarize: browsing directories, be it local or on an ftp site, you get some
pretty weird behaviour with the back and forward buttons.
The underlying problem seems to me that browsing through directories by clicking
on them doesn't add them to your browsing history, unless you click a text file,
apparantly.

I see this behaviour with both Win95 moz-build 2000040908 and Linux moz-build
2000040909.

Comment 11

19 years ago
Bill, is there a bug here?
Assignee: don → law
Target Milestone: M16 → M19

Comment 12

19 years ago
More than one, probably.  I'm going to send it to Radha, though.  Seems like 
more of a session history kind of thing.
Assignee: law → radha

Comment 13

19 years ago
Move to M20 target milestone.
Target Milestone: M19 → M20

Comment 14

19 years ago
Oops.  Should be M21.
Target Milestone: M20 → M21
Blocks: 47238
I could not reproduce any of the methods described here anymore. marking works 
forme.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 16

18 years ago
verified wfm
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.