If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

nsSHistory::GoBack/Forward's check is redundant

VERIFIED WONTFIX

Status

()

Core
Document Navigation
VERIFIED WONTFIX
17 years ago
9 years ago

People

(Reporter: Blake Ross, Assigned: Radha on family leave (not reading bugmail))

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
nsSHistory::GoBack (and its Forward counterpart) calls nsSHistory::GetCanGoBack 
before going back.  This seems a bit like a waste, because we have a canGoBack 
broadcaster that ensures that the user can't go back anyways (by updating the 
UI appropriately).  Is it better to force people to call GetCanGoBack first, or 
should they be allowed to just call GoBack unequivocably, which then checks 
implicitly?
I think GoBack() calling CanGoBack() is OK. The browser is not the only client 
to the SH. Some embedding applications may not choose to call CanGoback() and 
expect SH to do the job for them. I'm going to leave the code as it is.

Comment 2

17 years ago
I have to agree with radha on this one - what happens if an embedder calls
GoBack() when we're not allowed to go back.. we shouldn't barf, so we should
call CanGoBack()
There is no bug here.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
mass-verifying WontFix bugs which haven't changed since 2001-12-31.

use the search string "BoletusEdulis" if you want to filter out this msg.
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.