Closed Bug 3891 Opened 26 years ago Closed 25 years ago

[FEATURE] Remember page state in session history

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 16806

People

(Reporter: roland.mainz, Assigned: radha)

References

(
URL
)

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...)
Assignee: karnaze → pollmann
This is a local history issue.
Assignee: pollmann → radha
Component: HTMLFrames → Networking Library
QA Contact: 4082 → 4130
Hardware: PC → All
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.
Status: NEW → ASSIGNED
Target Milestone: M7 → M8
Move this one to M8 ...
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
More things to session History...
Depends on: 9958
This can be fixed only after 9958 is fixed. Moving to M12
Target Milestone: M9 → M12
Blocks: 10575
*** Bug 10008 has been marked as a duplicate of this bug. ***
Summary: [FEATURE]Remember the page's scrollbar position in sessionhistory → [FEATURE] Remember page state in session history
Blocks: 12651
Priority: P2 → P1
Can this be moved back to M11? Who needs to help to make this happen?
Depends on: 13058
*** Bug 16223 has been marked as a duplicate of this bug. ***
*** Bug 16376 has been marked as a duplicate of this bug. ***
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...
Priority: P1 → P2
[Resolving priority to level 2] P1 designations are reserved for crash-inducing bugs, yes?
Priority: P2 → P1
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 16806 ***
Status: RESOLVED → VERIFIED
VERIFIED dupe.
No longer blocks: 10575
No longer blocks: 12651
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.