I cannot repro the layout test failures, seeing if this helps.
TBR=hclam
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/155396
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20439 0039d316-1c4b-4281-b951-d872f2087c98
we're in the middle of a drag originating from the tab.
The problem is that the tab gets deleted out from under the
drag operation which is happening in a nested message loop.
To work around this, if we're in the middle of a drag and
we get a tab close request, delay the tab close until after
the drag operation is finished.
BUG=16280
Review URL: http://codereview.chromium.org/149466
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20436 0039d316-1c4b-4281-b951-d872f2087c98
We may need to make a few changes before we're ready for this to be live,
so we're disabling for now.
BUG=12117
TEST=none
Review URL: http://codereview.chromium.org/155388
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20433 0039d316-1c4b-4281-b951-d872f2087c98
When saving a page with no title, such as a text file, attempt to
use a sane value for the save name by retrieving the last component
of the URL (if one exists).
This prevents the case where a page http://www.foo.com/a/path/name.txt
is saved as file "http www" with extension type "foo.com a path name.txt".
This change also makes the SavePackage code a little more flexible
and simpler to test.
BUG=none
TEST=Covered by unittest.
Review URL: http://codereview.chromium.org/155266
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20432 0039d316-1c4b-4281-b951-d872f2087c98
As spotted by the valgrind ui_tests buildbot.
BUG=16473
Review URL: http://codereview.chromium.org/149486
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20428 0039d316-1c4b-4281-b951-d872f2087c98
Thus users can still use the home button until we get rid of the splash page.
BUG=16308
TEST=none.
Review URL: http://codereview.chromium.org/149481
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20427 0039d316-1c4b-4281-b951-d872f2087c98
BUG=none
TEST=double click on an unselected item, it should be activated
Review URL: http://codereview.chromium.org/155368
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20424 0039d316-1c4b-4281-b951-d872f2087c98
For now both the player and WebMediaPlayerImpl create a thread and inject its message loop into the pipeline. The end result is more-or-less the same as what we have today, but we could end up moving the pipeline onto the render thread.
BUG=16008
TEST=layout tests, media_unittests should pass
Review URL: http://codereview.chromium.org/155338
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20417 0039d316-1c4b-4281-b951-d872f2087c98
Previously we used a special Watcher object to watch the process,
but that is not portable to POSIX and this is simpler anyway.
With this change, I now see ~PluginProcessHost() running when a
plugin crashes.
If you recall all the way back to
http://codereview.chromium.org/16814
we did a similar thing to the renderer host.
Review URL: http://codereview.chromium.org/155331
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20414 0039d316-1c4b-4281-b951-d872f2087c98
The mouseover code I added to do *smart* tooltips was making DnD almost
unusable.
BUG=None
TEST=Drag thumbnails on the NNTP and they should move smoothly.
Review URL: http://codereview.chromium.org/149427
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20413 0039d316-1c4b-4281-b951-d872f2087c98
The most important part was refactoring PipelineImpl tests in preparation for message loop injection. The old mocks just did not work *at all* with my message loop injection patch.
BUG=16008
TEST=media_unittests should pass and not flake out
Review URL: http://codereview.chromium.org/149423
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20412 0039d316-1c4b-4281-b951-d872f2087c98
Added MediaLeakTest.BearH264 in test_shell_tests
to play a media file in test_shell. This is to
facilitate running purify to detect memory leaks
in the media player and <video>.
Review URL: http://codereview.chromium.org/155237
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20407 0039d316-1c4b-4281-b951-d872f2087c98
* Reset the drop info when completing a drag (successful or otherwise).
* Reset the drop info when the drag leaves the tab strip zone.
* Report success or failure of the drop back to the source widget.
* Move and resize the drop arrow container before showing it to reduce visual jank.
BUG=none
TEST=Drag a image into the tab strip so that the drop arrow appears. Release the drop over the tab strip and then move the window and repeat the process. The drop arrow should be in the correct position. Notice that there is no visual jank when the drop arrow is shown.
Review URL: http://codereview.chromium.org/149426
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20404 0039d316-1c4b-4281-b951-d872f2087c98
(This does not change the button image.)
Review URL: http://codereview.chromium.org/155365
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20403 0039d316-1c4b-4281-b951-d872f2087c98
This reverts commit r20399 and re-applies the button tinting
code. There's a fix for the go button gtk unittest by checking
to see if the browser is non-NULL before getting the theme provider.
TBR=erg
Review URL: http://codereview.chromium.org/155369
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20402 0039d316-1c4b-4281-b951-d872f2087c98
BUG=none
TEST=Official builds still auto update and have breakpad.
Review URL: http://codereview.chromium.org/155364
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20401 0039d316-1c4b-4281-b951-d872f2087c98
This should make it non-flaky, so I un-disabled the test. I also added necessary plumbing so we can
wait for AppModalDialog to appear and close it.
TEST=Covered by browser_tests.
http://crbug.com/16062
Review URL: http://codereview.chromium.org/149460
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20400 0039d316-1c4b-4281-b951-d872f2087c98
Markus pointed out that the cwd was already shared between the chroot
helper process and the zygote, therefore we could avoid some
complexity in passing the file descriptor so, also, we could then make
the directory mode 0000.
http://codereview.chromium.org/155366
BUG=16363
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20398 0039d316-1c4b-4281-b951-d872f2087c98
Make CustomDrawButtonBase aware of the ThemeProvider. If the
theme changes, we reload new pixbufs from the ThemeProvider.
This breaks RTL of the toolbar buttons, I'll add that back
in a follow up change to BrowserThemeProvider.
BUG=15506
TEST=Change themes or set the GTK+ theme. The star button and go button should be tinted according to the theme (other buttons as well if not using GTK+ buttons).
Review URL: http://codereview.chromium.org/149432
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20396 0039d316-1c4b-4281-b951-d872f2087c98
We were forcing the IME to close during the process of updating the edit, which in turn caused us to try and handle "changes to the edit", leading to us (wrongly) rerunning autocomplete and blowing away our result set.
BUG=13500
TEST=On XP, open a new tab, set the (Microsoft) IME to Hiragana, type 'c', and then click an entry in the popup. The browser should navigate, not crash.
Review URL: http://codereview.chromium.org/155330
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20395 0039d316-1c4b-4281-b951-d872f2087c98
BUG=crbug.com/15642
TEST=select version in about box; copy/paste it somewhere.
Review URL: http://codereview.chromium.org/155361
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20394 0039d316-1c4b-4281-b951-d872f2087c98
The spacing between the toolbar buttons now matches windows pixel for pixel (tested empirically).
The bookmark bar item spacing is now a little better, but we need some hackery to improve it to the state of windows (we need to annex about 5 pixels from the toolbar when the bookmark bar is open).
The code for packing bookmark bar buttons is now all in one place.
Functional change: There will be no other bookmarks button until the model is loaded. If you care I can fix this, it just doesn't seem like a very important matter since it's unusable anyway when the model isn't loaded.o
I also removed a log warning from chrome_dll_main because with this change it started spamming a lot. We're already living with this warning, and have a bug filed for it (they fixed the root problem in newer versions of gtk so I think this bug will just never get resolved), so I don't think this is a big deal.
BUG=15870
TEST=things look marginally better, theming still works properly
Review URL: http://codereview.chromium.org/155342
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20389 0039d316-1c4b-4281-b951-d872f2087c98
Ubuntu systems (at least) wipe /var/run at boot time, which is
deleting our sandbox directory. Instead, we have the SUID helper
create a temp directory in /tmp, unlink it and use that for the chroot
directory. A file descriptor is passed to the zygote process for it to
fchdir into.
(Thanks to fta for discussions on this.)
BUG=16363
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20388 0039d316-1c4b-4281-b951-d872f2087c98
scherkus@chromium.org