Browser History:Redirects: Difference between revisions

Jump to navigation Jump to search
Line 104: Line 104:
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. Probably adding an additional method is preferrable; the GeckoFlags function was successfully added without too much pain to GlobalHistory2 in Firefox 1.5.
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. Probably adding an additional method is preferrable; the GeckoFlags function was successfully added without too much pain to GlobalHistory2 in Firefox 1.5.


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.
Session history entries would be extended to support nsIWritablePropertyBag. When the history system gets visit notifications, it can store necessary state on the corresponding entry (probably just a 64-bit visit ID number). This way, it can associate a given call with a specific referring visit, 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 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.
Line 114: Line 114:
* New virtual function OnRedirectStateChange in docloader.
* New virtual function OnRedirectStateChange in docloader.


* Move redirect code from OnStateChange to OnRedirectStateChange.
* Move HTTP 30X redirect code from OnStateChange to OnRedirectStateChange.


* Change docshell AddToGlobalHistory to use the new AddURIFrom if history QIs to nsIGlobalHistory3 (or use new function in nsIGlobalHistory2).
* Change docshell AddToGlobalHistory to use the new AddURIFrom history function.


* Implement nsIWritablePropertyBag on the docshell.
* Implement nsIWritablePropertyBag on nsISHistoryEntry
202

edits

Navigation menu