Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the BSD License.
©2012 Google
Use the chrome.history
module to interact with the
browser's record of visited pages. You can add, remove, and query
for URLs in the browser's history.
To override the history page with your own version, see
Override Pages.
You must declare the "history" permission in the extension manifest to use the history API. For example:
{ "name": "My extension", ... "permissions": [ "history" ], ... }
The history API uses a transition type to describe how the browser navigated to a particular URL on a particular visit. For example, if a user visits a page by clicking a link on another page, the transition type is "link".
The following table describes each transition type.
Transition type | Description |
---|---|
"link" | The user got to this page by clicking a link on another page. |
"typed" | The user got this page by typing the URL in the address bar. Also used for other explicit navigation actions. See also generated, which is used for cases where the user selected a choice that didn't look at all like a URL. |
"auto_bookmark" | The user got to this page through a suggestion in the UI — for example, through a menu item. |
"auto_subframe" | Subframe navigation. This is any content that is automatically loaded in a non-top-level frame. For example, if a page consists of several frames containing ads, those ad URLs have this transition type. The user may not even realize the content in these pages is a separate frame, and so may not care about the URL (see also manual_subframe). |
"manual_subframe" | For subframe navigations that are explicitly requested by the user and generate new navigation entries in the back/forward list. An explicitly requested frame is probably more important than an automatically loaded frame because the user probably cares about the fact that the requested frame was loaded. |
"generated" | The user got to this page by typing in the address bar and selecting an entry that did not look like a URL. For example, a match might have the URL of a Google search result page, but it might appear to the user as "Search Google for ...". These are not quite the same as typed navigations because the user didn't type or see the destination URL. See also keyword. |
"start_page" | The page was specified in the command line or is the start page. |
"form_submit" | The user filled out values in a form and submitted it. Note that in some situations — such as when a form uses script to submit contents — submitting a form does not result in this transition type. |
"reload" | The user reloaded the page, either by clicking the reload button or by pressing Enter in the address bar. Session restore and Reopen closed tab use this transition type, too. |
"keyword" | The URL was generated from a replaceable keyword other than the default search provider. See also keyword_generated. |
"keyword_generated" | Corresponds to a visit generated for a keyword. See also keyword. |
For examples of using this API, see the history sample directory and the history API test directory. For other examples and for help in viewing the source code, see Samples.
Searches the history for the last visit time of each page matching the query.
The callback parameter should specify a function that looks like this:
function(array of HistoryItem results) {...};
Adds a URL to the history at the current time with a transition type of "link".
If you specify the callback parameter, it should specify a function that looks like this:
function() {...};
Removes all items within the specified date range from the history. Pages will not be removed from the history unless all visits fall within the range.
The callback parameter should specify a function that looks like this:
function() {...};
Deletes all items from the history.
Fired when a URL is visited, providing the HistoryItem data for that URL. This event fires before the page has loaded.