Browser History:Redirects: Difference between revisions

Line 110: Line 110:
Add a virtual function to nsDocLoader "OnRedirectStateChange". This function would be called manually from OnChannelRedirect will full information on the source and destionation channels. DocShell will provide an implementation of this function, and we can move the redirect handling code from OnStateChange to there.
Add a virtual function to nsDocLoader "OnRedirectStateChange". This function would be called manually from OnChannelRedirect will full information on the source and destionation channels. DocShell will provide an implementation of this function, and we can move the redirect handling code from OnStateChange to there.


This redirect function would attempt to QueryInterface the global history to a new interface we define (let's call it nsIGlobalHistory3 for now). If unsuccessful, it would revert to calling the old nsIGlobalHistory2.AddURI. Otherwise, it would call nsIGlobalHistory3.AddURIFrom and give it information about the redirect and a pointer to the docshell.
We could add a new redirect function to the existing nsIGlobalHistory2 or add it in a new interface nsIGlobalhistory3. Adding to the existing interface is cleaner, but would force embedders to update their history code. A new interface could be optional (docshell would fall back on AddURI if history didn't QI to nsIGlobalHistory3) so embedders would not have to change, but it would make history more difficult to understand.


The "regular" calls to AddURI would also be changed to use the new AddURIFrom function.
The docshell would be extended to support nsIWritablePropertyBag. When the history system gets visit notifications, it can store necessary state on the docshell (probably just a 64-bit visit ID number). This way, it can associate a given page visit as coming from a specific docshell, and know which specific page visit it came from, even if the same document is open in more than one docshell.


The docshell will be extended to support nsIWritablePropertyBag. When the history system gets visit notifications, it can store necessary state on the docshell (probably just a 64-bit visit ID number). This way, it can associate a given page visit as coming from a specific docshell, and know which specific page visit it came from, even if the same document is open in more than one docshell.
Global history would maintain queues of URLs for typed and bookmarked flags. When new URLs come through that have no referrer, it would check these queues to see if the URL had either of these flags set. This requires no changes to non-history system code, but it could be confused in some unusual cases (for example, if the user types and and follows a bookmark in quick succession for the same URL). The side effect of getting it wrong is very minor.


Global history would maintain queues of URLs for typed and bookmarked flags. When new URLs come through that have no referrer, it would check these queues to see if the URL had either of these flags set. This requires no changes to non-history system code, but it could be confused in some unusual cases (for examples, if the user types and and follows a bookmark in quick succession for the same URL). The side effect of getting it wrong is very minor.
Review of changes in docshell code:


Review of changes in old code:
* New nsIGlobalHistory3 interface defined in docshell/base or add to nsiGlobalHistory3.
 
* New nsIGlobalHistory3 interface defined in docshell/base OR add to nsiGlobalHistory3


* New virtual function OnRedirectStateChange in docloader.
* New virtual function OnRedirectStateChange in docloader.
202

edits