| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
now. I need to wait for the bookmark bar to become visible so I plumbed in similar code as for the Find box instead of using Sleep's.
Review URL: http://codereview.chromium.org/473
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1809 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
slight tweak to how RestoreWindowPosition on Window works - if the window is opened with specified bounds, we still ask the delegate to try and restore the position. The delegate can use the provided bounds as a hint (in the popup case the bounds aren't the true layout bounds of the window, rather the rect contains the window position and content area size) to return the actual bounds of the window.
B=1031854
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1117 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- makes more stuff in Browser object only happen if you're using the old frames- rename BrowserWindow::Update to BrowserWindow::UpdateToolbar since that's what it does
- add window position save/restore handling to Browser- remove BrowserWindow::BrowserDidPaint
- relic from HaloFrame days- remove BrowserWindow::GetRootView - unused and exposes impl details- remove BrowserWindow::DetachFromBrowser - unused
- store BrowserView2* on HWND's property list so infobubbles can access it later- both frames (Opaque and AeroGlass) notify the BrowserView2 when they're moved so BrowserView2 can reposition the status bubble and close the autocomplete popup
- remove BrowserView2::ShowTabContents - no longer used
- remove BrowserView2::ShelfVisibilityChanged - no longer used
- remove BrowserView2::SetWindowTitle - never used
- remove BrowserView2::ProfileChanged - now called from TabSelectedAt- properly unhook infobars etc when a tab is detached
B=1031854
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@660 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
going to become more methodical about this soon, I promise.
B=1031854
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@377 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
|
| |
|
|
|
|
|
|
| |
Yes this causes duplicate code, but only for a brief while until I can bring up BrowserView at which point this code will move from the frames to that object. "It gets worse before it gets better".
B=1031854
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@213 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
This causes some temporary duplication of code in xp/vista frames but it will be temporary. My goal is to move all the top level browser level views into the frames. From there, I will move them from the frames into their new home - BrowserView (chrome/browser/views/frames/browser_view.cc), and each frame will host a BrowserView. This will reduce duplication of code.
To make this change I had to add a bunch of methods to the BrowserWindow (nee ChromeFrame) interface to provide access to some of the toolbar's contents. Excuse the ugly API, we will be improving this incrementally.
B=1031854
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205 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
|
