Closed
Bug 3891
Opened 26 years ago
Closed 25 years ago
[FEATURE] Remember page state in session history
Categories
(SeaMonkey :: UI Design, defect, P1)
SeaMonkey
UI Design
Tracking
(Not tracked)
M12
People
(Reporter: roland.mainz, Assigned: radha)
References
()
Details
THe previous page's Y position is not restored when clicking on the
"Back"-Button.
Example: Go to http://www.scripting.com, move into the middle of the page,
click/visit a link, then go "Back". You'll end at the top of www.scripting.com,
not in the middle.
Other note:
Be !! sure !! that the cache does mark incomplete loaded documents/files, and
that error codes like 4xx (405 etc) are not cached (as documents... the server
may return a description as HTML file, but it may not be the requested one...)
Updated•26 years ago
|
Assignee: karnaze → pollmann
Comment 1•26 years ago
|
||
This is a local history issue.
Updated•26 years ago
|
Assignee: pollmann → radha
Updated•26 years ago
|
Hardware: PC → All
Comment 2•26 years ago
|
||
yeah, i just figured no one got around to implementing this yet. the bug is cross platform, marking as such.
Component: Networking Library → XPApps
OS: Windows NT → All
Priority: P3 → P2
Target Milestone: M7
Set target milestone to M7, changed component to XPApps and priority to P2.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•26 years ago
|
Summary: The previous page's Y pos is not restored when doing "back" → [FEATURE]Remember the page's scrollbar position in sessionhistory
Target Milestone: M8 → M9
Assignee | ||
Comment 5•26 years ago
|
||
More things to session History...
Assignee | ||
Comment 6•26 years ago
|
||
This can be fixed only after 9958 is fixed. Moving to M12
Assignee | ||
Updated•26 years ago
|
Target Milestone: M9 → M12
Summary: [FEATURE]Remember the page's scrollbar position in sessionhistory → [FEATURE] Remember page state in session history
Comment 10•25 years ago
|
||
*** Bug 16376 has been marked as a duplicate of this bug. ***
Comment 11•25 years ago
|
||
I filed bug 16376 when I was unable to find this one. A few important comments
from that bug:
One tricky issue with this bug is named anchors: you want to preserve the
position *separately* for each named anchor. (This is unlike form controls (see
bug 16379), where I think you want to hold the data even when the named anchor
changes.)
This should be tested carefully with frames, too...
Comment 12•25 years ago
|
||
[Resolving priority to level 2]
P1 designations are reserved for crash-inducing bugs, yes?
Updated•25 years ago
|
Priority: P2 → P1
Comment 13•25 years ago
|
||
Setting priority back to P1. The priority field is used by the bug owner to
prioritize work. I know that Kipp prefers to use P1 only for crashers, but that
doesn't mean everyone does.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 14•25 years ago
|
||
*** This bug has been marked as a duplicate of 16806 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 15•25 years ago
|
||
VERIFIED dupe.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•