| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
reenables the code in ExpireHistoryBackend. I also madethe code consistent so that when we delete visits as the result ofhistory deletion we don't change the typed/visit count of theunderlying url.BUG=1214201 1256202TEST=none
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1423 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
parts of the code (I'm trying to clean up WebContents). We can ressurect this if we have a better plan for doing profiling that needs to live in the browser.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1341 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Interesting points:
. Migration was a bit atypical. Here is the approach I took:
. If the URL db contains bookmarks it writes the bookmarks to a
temporary file.
. When the bookmark bar model is loaded it assumes bookmarks are
stored in a file. If the bookmarks file doesn't exist it then
attempts to load from history, after waiting for history to finish
processing tasks.
. I've broken having the omnibox query for starred only. This patch
was already too ginormous for me to contemplate this too. I'll return
to it after I land this.
. Similarly the history page isn't searching for starred titles
now. As we discussed with Glen, that is probably fine for now.
. I've converted NOTIFY_STARRED_FAVICON_CHANGED to
NOTIFY_FAVICON_CHANGED and it is notified ANY time a favicon
changes. I'm mildly concerned about the extra notifications, but
without having history know about starred it's the best I can do for
now.
. Autocomplete (specifically URLDatabase::AutocompleteForPrefix)
previously sorted by starred. It can no longer do this. I don't
think I can get this functionality back:( Luckily it only mattered
if you had a starred and non-starred URL with the same type count
that matched a query. Probably pretty rare.
What's left:
. Fix up HistoryContentsProvider to query for starred entries titles.
. Clean up the delete all case. I basically just made it compile; it
can be greatly simplified.
. Rename BookmarkBarModel to BookmarksModel.
BUG=1256202
TEST=this is a huge change to bookmarks. Thanfully it's pretty well
covered by tests, none-the-less make sure you exercise bookmarks
pretty heavily to make sure nothing is busted.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1153 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
This fixes a leak of NavigationEntry's by using the spiffy linked ptr. I had to
add a const to linked_ptr for the comparisons to work.
BUG=1319484
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1137 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
- Slightly reduce the size of the generated .lib files ~3%.
- Reduce the number of implicit and explicit atl and windows includes. hooray!
- Help incremental build by reducing the number of unnecessary included files.
- Split some template class in two, one base class for the common code and the specialization that inherits from the base class.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@937 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
| |
with a test.
BUG=none
TEST=none; just make sure context menu for bookmark bar still works
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@805 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
and browser_views.lib(65 source files, 30 megs).
This will hopefully improve link time (well, not as much as I'd like) and will definitely help non-IB compilation parallelization.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@796 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
RenderViewHostManager object.
The goal for this patch is to change no logic or APIs, just move the code. So
there are some not very clean callback functions and no new unit tests for this
file (although is is still covered by the same WebContents unit tests). This
should make the actual cleanup in a later pass much easier to follow.
I changed the ordering of only a few operations (like WebContents shutdown), and checked that this shouldn't matter. I had to change the "source" for several notifications since they are no longer sent from the WebContents.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@716 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
rendering HTML as an arbitrary browser view. DOMView currently does something
like this, but it uses TabContents and is hence pretty heavyweight. We may be
able to replace DOMView with HWNDHtmlView.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@656 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
* reformat page
* use new product image rather than an http link to google.com
BUG=1300256
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@465 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I've hidden this frame behind a command line switch (--magic_browzR) so as not to destabilize the main browser UI any further. Note that running with this switch is likely buggy, incomplete, crashy, etc.
In order to make this work without disrupting a lot of existing code, I've had to make another BrowserView class (temporary) - BrowserView2. This also has to be a BrowserWindow implementor since that's the interface Browser uses to communicate with the UI.
BrowserView2 and OpaqueNonClientView are the major new files in this CL, but BrowserView2 is pretty similar to BrowserView. OpaqueNonClientView is the view that renders the titlebar/borders/etc. It's layout/painting routines are a bit simpler than XPFrame's!
B=1031854
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@329 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BrowserToolbarView and StatusBubble into it.
Also restructures the creation of the Frame. This is significant! The Browser now constructs a frame via a new static BrowserWindow::CreateBrowserWindow method (see browser_window_factory.cc). Recall the diagram in the architectural overview doc - the BrowserView object is the one that implements the interface that the Browser object uses to communicate with the UI. The Browser object communicates to the BrowserView directly through this interface, but not directly to the frame.
What actually happens right now in CreateBrowserWindow is that an XP/VistaFrame is constructed, but this is _not_ the object returned to the Browser, rather when the XP/VistaFrame is init'ed, it constructs a BrowserView that also implements BrowserWindow. This is the object that's returned to the Browser.
Since both BrowserView and XP/VistaFrame implement BrowserWindow, I am now able to gradually migrate functionality from the frames to BrowserView. During this process BrowserWindow functions not handled yet by BrowserView will be forwarded to the appropriate frame.
Modifies the Accessibility UI tests to account for this extra level of indirection (should only be temporary while I'm moving things around).
This does actually pass the UI tests.
See the whiteboard in my office for a diagram. This is a bit confusing right now since there's so much going on. Sadly the only way to get where we need to go incrementally is to make a mess on the way.
B=1031854
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@245 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
B=1031854
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@168 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
Move static utility functions to FrameUtil class.
B=1294302
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@102 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
|
