summaryrefslogtreecommitdiffstats
path: root/content
Commit message (Collapse)AuthorAgeFilesLines
* Merge 251289 "Fix the crash issue caused by vibrate permission"benm@chromium.org2014-02-191-2/+13
| | | | | | | | | | | | | | | | | | > Fix the crash issue caused by vibrate permission > > The app will be crashed when using vibrate API, without VIBRATE permission specified. > Catch the security exception instead of crash should be more friendly. > > BUG=338151 > TEST= > > Review URL: https://codereview.chromium.org/143673004 TBR=guangzhen.li@intel.com Review URL: https://codereview.chromium.org/172343002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@252016 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 244116 "<webview>: Support zoom in WebUI"xiyuan@chromium.org2014-02-188-8/+33
| | | | | | | | | | | | | | | | | | | > <webview>: Support zoom in WebUI > > This CL plumbs the embedder's zoom into the guest WebContents. > > BUG=330818 > > Review URL: https://codereview.chromium.org/98073015 Needed for kiosk app as well. BUG=341235 TBR=fsamuel@chromium.org Review URL: https://codereview.chromium.org/166883004 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@251735 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 243893 "BrowserPlugin: Implemented BrowserPluginGuestManag..."laforge@chromium.org2014-02-184-40/+48
| | | | | | | | | | | | | | | | > BrowserPlugin: Implemented BrowserPluginGuestManager::ForEachGuest > > Use this pattern to replace existing methods in BrowserPluginGuestManager. This CL is just a refactor, there is no change in functionality. > > BUG=330843 > > Review URL: https://codereview.chromium.org/128563002 TBR=fsamuel@chromium.org Review URL: https://codereview.chromium.org/169443008 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@251728 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 251024 "Allow retrieval of media device ID salt even after..."joi@chromium.org2014-02-1713-74/+100
| | | | | | | | | | | | | | | > Allow retrieval of media device ID salt even after ResourceContext has gone away. > > TBR=willchan@chromium.org > BUG=341211 > > Review URL: https://codereview.chromium.org/143003031 TBR=joi@chromium.org Review URL: https://codereview.chromium.org/169553002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@251660 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 251420 "Clear the pending_and_current_web_ui_ if we reuse it."creis@chromium.org2014-02-142-2/+31
| | | | | | | | | | | | | | | | | > Clear the pending_and_current_web_ui_ if we reuse it. > > R=nasko@chromium.org > TBR=estade@chromium.org > BUG=330811 > TEST=See bug comment 9 for repro steps. > > Review URL: https://codereview.chromium.org/166033006 TBR=creis@chromium.org Review URL: https://codereview.chromium.org/167813002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@251435 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 251428 "Merge 251420 "Clear the pending_and_current_web_u..."laforge@chromium.org2014-02-142-31/+2
| | | | | | | | | | | | | | | | | | | | | | | > Merge 251420 "Clear the pending_and_current_web_ui_ if we reuse it." > > > Clear the pending_and_current_web_ui_ if we reuse it. > > > > R=nasko@chromium.org > > TBR=estade@chromium.org > > BUG=330811 > > TEST=See bug comment 9 for repro steps. > > > > Review URL: https://codereview.chromium.org/166033006 > > TBR=creis@chromium.org > > Review URL: https://codereview.chromium.org/167743002 TBR=laforge@chromium.org Review URL: https://codereview.chromium.org/167313003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@251431 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 251420 "Clear the pending_and_current_web_ui_ if we reuse it."laforge@chromium.org2014-02-142-2/+31
| | | | | | | | | | | | | | | | | > Clear the pending_and_current_web_ui_ if we reuse it. > > R=nasko@chromium.org > TBR=estade@chromium.org > BUG=330811 > TEST=See bug comment 9 for repro steps. > > Review URL: https://codereview.chromium.org/166033006 TBR=creis@chromium.org Review URL: https://codereview.chromium.org/167743002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@251428 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 248903 "hide the input method window when the user is done..."sgurun@chromium.org2014-02-142-1/+42
| | | | | | | | | | | | | | > hide the input method window when the user is done typing > > BUG=340100 > > Review URL: https://codereview.chromium.org/132913007 TBR=hush@chromium.org Review URL: https://codereview.chromium.org/166273003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@251386 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 247572 "Linux: tear down Zygote at browser shutdown."jln@chromium.org2014-02-143-22/+101
| | | | | | | | | | | | | | | | | | | | | | | | | > Linux: tear down Zygote at browser shutdown. > > In BrowserMainLoop::ShutdownThreadsAndCleanUp(), we explicitly call > a new ZygoteHostImpl::TearDownAfterLastChild API to notify the Zygote > to exit after its last child died. > > The notification is to simply close the IPC channel to the Zygote. > Before this patch, this would happen implicitly when the browser process > died. > > To implement this, we add a lightweight child tracking mechanism to ZygoteHostImpl. > > BUG=334345 > R=piman@chromium.org > > Review URL: https://codereview.chromium.org/148443006 TBR=jln@chromium.org Review URL: https://codereview.chromium.org/166163002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@251263 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 249937 "Linux Sandbox: Stop GPU watchdog in accountable way."jln@chromium.org2014-02-133-30/+87
| | | | | | | | | | | | | | | | | | | | | > Linux Sandbox: Stop GPU watchdog in accountable way. > > The Linux sandbox can sometimes detect a spurious running thread if it > has just been stopped. > > We add a new LinuxSandbox::StopThread() method to safely stop threads > and make sure they won't be counted as still running. > > BUG=328620 > NOTRY=true > > Review URL: https://codereview.chromium.org/147203005 TBR=jln@chromium.org Review URL: https://codereview.chromium.org/164583002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@251107 0039d316-1c4b-4281-b951-d872f2087c98
* V4L2VDA: Fix a few bugs related to Reset() and buffer management.posciak@chromium.org2014-02-133-86/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - If a Reset() arrived before the first Decode(), or, in general, if it arrived before V4L2VDA requested buffers, it would assume it had already have allocated buffers and go back to kDecoding before resuming. Fix this by checking if the buffers are allocated before resuming and go back to kInitialized state, instead of kAfterReset. This only works because we also now make buffer allocation an "atomic" operation for the decoder thread (see below). - If a Reset() arrived after V4L2VDA had a chance to request buffers, but before AssignPictureBuffers() and AssignPictureBuffersTask() resulted in finishing the buffer allocation sequence, ResetTask would call StopDevicePoll(), assume the buffers were good for reuse, and queue them to the free output buffer queue. They would still be missing textures though and not be ready for reuse, but the decoding would continue. Moreover, the AssignPictureBuffersTask() would re-queue them to the free queue again. Fix this by simply making the decoder thread wait for AssignPictureBuffers before continuing decoding. This doesn't have too much perf impact and should solve some other potential corner cases, similar to the one above. With this, we don't need the AssignPictureBuffersTask anymore, and can do everything in AssignPictureBuffers, while the decoder thread waits. Separately, don't bail out with an error in a situation when we've already posted a DismissPictureBuffer for a PictureBuffer to the client and cleared the corresponding metadata, but it has not yet executed in client before it had a chance to post a ReusePictureBuffer for it back to us. Verifying that this exact situation occurred however and not a random picture id was returned is difficult/impossible and not worth it in general, so just ignore such buffers (they will have been already freed). Finally, mark all buffers as not in device after streamoff, and not only those that are known to be in client; V4L2 spec mandates that the device is to drop ownership of all queued buffers regardless of whether we dequeue them in this case. To test these situations: - enable the ResetBeforeDecode test for V4L2VDA; this tests for Reset()s before the Decode() with first config info is called; - add a new ResetAfterFirstConfigChange case to test situations where Reset() is called immediately after Decode() with first config info, which tests how VDA handles Reset() after it had a chance to request buffers, but before receiving them back. Also, fix ResetBeforeDecode test to work again, as it seems to have been accidentally broken by the recent refactoring. Finally, if a stream is shorter than kMaxResetAfterFrameNum, reset in the middle of it, instead of resetting after first frame arrives. BUG=319495,chrome-os-partner:21063 TEST=vdatest, MSE tests, seek tests, res switch tests, youtube with &t=1m Review URL: https://codereview.chromium.org/151293003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250955 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 250948 "V4L2VDA: Fix a few bugs related to Reset() and bu..."posciak@chromium.org2014-02-133-172/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverting erroneous merge. > V4L2VDA: Fix a few bugs related to Reset() and buffer management. > > - If a Reset() arrived before the first Decode(), or, in general, if it > arrived before V4L2VDA requested buffers, it would assume it had already > have allocated buffers and go back to kDecoding before resuming. > > Fix this by checking if the buffers are allocated before resuming and go > back to kInitialized state, instead of kAfterReset. This only works because > we also now make buffer allocation an "atomic" operation for the decoder > thread (see below). > > - If a Reset() arrived after V4L2VDA had a chance to request buffers, but > before AssignPictureBuffers() and AssignPictureBuffersTask() resulted in > finishing the buffer allocation sequence, ResetTask would call > StopDevicePoll(), assume the buffers were good for reuse, and queue them to > the free output buffer queue. They would still be missing textures though > and not be ready for reuse, but the decoding would continue. Moreover, the > AssignPictureBuffersTask() would re-queue them to the free queue again. > > Fix this by simply making the decoder thread wait for AssignPictureBuffers > before continuing decoding. This doesn't have too much perf impact and > should solve some other potential corner cases, similar to the one above. > > With this, we don't need the AssignPictureBuffersTask anymore, and can > do everything in AssignPictureBuffers, while the decoder thread waits. > > Separately, don't bail out with an error in a situation when we've already > posted a DismissPictureBuffer for a PictureBuffer to the client and cleared > the corresponding metadata, but it has not yet executed in client before > it had a chance to post a ReusePictureBuffer for it back to us. > Verifying that this exact situation occurred however and not a random > picture id was returned is difficult/impossible and not worth it in > general, so just ignore such buffers (they will have been already freed). > > Finally, mark all buffers as not in device after streamoff, and not only > those that are known to be in client; V4L2 spec mandates that the device > is to drop ownership of all queued buffers regardless of whether we dequeue > them in this case. > > To test these situations: > - enable the ResetBeforeDecode test for V4L2VDA; this tests for Reset()s > before the Decode() with first config info is called; > - add a new ResetAfterFirstConfigChange case to test situations where > Reset() is called immediately after Decode() with first config info, which > tests how VDA handles Reset() after it had a chance to request buffers, > but before receiving them back. > > Also, fix ResetBeforeDecode test to work again, as it seems to have been > accidentally broken by the recent refactoring. > > Finally, if a stream is shorter than kMaxResetAfterFrameNum, reset in the > middle of it, instead of resetting after first frame arrives. > > BUG=319495,chrome-os-partner:21063 > TEST=vdatest, MSE tests, seek tests, res switch tests, youtube with &t=1m > R=fischman@chromium.org, sheu@chromium.org > > Review URL: https://codereview.chromium.org/151293003 > > TBR=posciak@chromium.org Review URL: https://codereview.chromium.org/162713004 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250954 0039d316-1c4b-4281-b951-d872f2087c98
* V4L2VDA: Fix a few bugs related to Reset() and buffer management.posciak@chromium.org2014-02-133-86/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - If a Reset() arrived before the first Decode(), or, in general, if it arrived before V4L2VDA requested buffers, it would assume it had already have allocated buffers and go back to kDecoding before resuming. Fix this by checking if the buffers are allocated before resuming and go back to kInitialized state, instead of kAfterReset. This only works because we also now make buffer allocation an "atomic" operation for the decoder thread (see below). - If a Reset() arrived after V4L2VDA had a chance to request buffers, but before AssignPictureBuffers() and AssignPictureBuffersTask() resulted in finishing the buffer allocation sequence, ResetTask would call StopDevicePoll(), assume the buffers were good for reuse, and queue them to the free output buffer queue. They would still be missing textures though and not be ready for reuse, but the decoding would continue. Moreover, the AssignPictureBuffersTask() would re-queue them to the free queue again. Fix this by simply making the decoder thread wait for AssignPictureBuffers before continuing decoding. This doesn't have too much perf impact and should solve some other potential corner cases, similar to the one above. With this, we don't need the AssignPictureBuffersTask anymore, and can do everything in AssignPictureBuffers, while the decoder thread waits. Separately, don't bail out with an error in a situation when we've already posted a DismissPictureBuffer for a PictureBuffer to the client and cleared the corresponding metadata, but it has not yet executed in client before it had a chance to post a ReusePictureBuffer for it back to us. Verifying that this exact situation occurred however and not a random picture id was returned is difficult/impossible and not worth it in general, so just ignore such buffers (they will have been already freed). Finally, mark all buffers as not in device after streamoff, and not only those that are known to be in client; V4L2 spec mandates that the device is to drop ownership of all queued buffers regardless of whether we dequeue them in this case. To test these situations: - enable the ResetBeforeDecode test for V4L2VDA; this tests for Reset()s before the Decode() with first config info is called; - add a new ResetAfterFirstConfigChange case to test situations where Reset() is called immediately after Decode() with first config info, which tests how VDA handles Reset() after it had a chance to request buffers, but before receiving them back. Also, fix ResetBeforeDecode test to work again, as it seems to have been accidentally broken by the recent refactoring. Finally, if a stream is shorter than kMaxResetAfterFrameNum, reset in the middle of it, instead of resetting after first frame arrives. BUG=319495,chrome-os-partner:21063 TEST=vdatest, MSE tests, seek tests, res switch tests, youtube with &t=1m R=fischman@chromium.org, sheu@chromium.org Review URL: https://codereview.chromium.org/151293003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250948 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 250525 "android: Remove RenderWidgetHostViewAndroid's poin..."feng@chromium.org2014-02-121-0/+6
| | | | | | | | | | | | | | | | | | | > android: Remove RenderWidgetHostViewAndroid's pointer to ContentViewCore when swapped > > The change from https://codereview.chromium.org/26753005/ is causing crashes > due to unclear lifetimes of ContentViewCore with respect to > RenderWidgetHostViewAndroid. In this patch, we remove the pointer from > RWHV to CVC when RWHV is swapped out. > > BUG=324341 > > Review URL: https://codereview.chromium.org/149753008 TBR=powei@chromium.org Review URL: https://codereview.chromium.org/160853002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250771 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 248631 "Transfer appcache state during cross site navigati..."michaeln@google.com2014-02-122-0/+8
| | | | | | | | | | | | | | | | | | | | > Transfer appcache state during cross site navigations too. > > The AppCacheHost is an object that persist across the lifetime of a document. It's created prior to the document and prior to the initiation of the resource load for the documents main resource. Today, when a cross-site xfer occurs the host is deleted and a new host is created that knows nothing of whats going on... so not surprisingly things are broken. > > Either state of the old host that gets deleted needs to be saved and restored into a new host that gets created... or the old host should not get deleted and instead get transferred along as well. > > I chose the latter because there's some state that can't be saved/restored so easily and moving the whole object is less tedious. > > BUG=331270 > > Review URL: https://codereview.chromium.org/137883005 TBR=michaeln@chromium.org Review URL: https://codereview.chromium.org/144193006 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250606 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 250553 "Merge 248819 "V4L2VDA: Fix a few bugs related to ..."posciak@chromium.org2014-02-121-76/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert due to error in conflict resolution. Will merge again. > Merge 248819 "V4L2VDA: Fix a few bugs related to Reset() and buf..." > > > V4L2VDA: Fix a few bugs related to Reset() and buffer management. > > > > - If a Reset() arrived before the first Decode(), or, in general, if it > > arrived before V4L2VDA requested buffers, it would assume it had already > > have allocated buffers and go back to kDecoding before resuming. > > > > Fix this by checking if the buffers are allocated before resuming and go > > back to kInitialized state, instead of kAfterReset. This only works because > > we also now make buffer allocation an "atomic" operation for the decoder > > thread (see below). > > > > - If a Reset() arrived after V4L2VDA had a chance to request buffers, but > > before AssignPictureBuffers() and AssignPictureBuffersTask() resulted in > > finishing the buffer allocation sequence, ResetTask would call > > StopDevicePoll(), assume the buffers were good for reuse, and queue them to > > the free output buffer queue. They would still be missing textures though > > and not be ready for reuse, but the decoding would continue. Moreover, the > > AssignPictureBuffersTask() would re-queue them to the free queue again. > > > > Fix this by simply making the decoder thread wait for AssignPictureBuffers > > before continuing decoding. This doesn't have too much perf impact and > > should solve some other potential corner cases, similar to the one above. > > > > With this, we don't need the AssignPictureBuffersTask anymore, and can > > do everything in AssignPictureBuffers, while the decoder thread waits. > > > > Separately, don't bail out with an error in a situation when we've already > > posted a DismissPictureBuffer for a PictureBuffer to the client and cleared > > the corresponding metadata, but it has not yet executed in client before > > it had a chance to post a ReusePictureBuffer for it back to us. > > Verifying that this exact situation occurred however and not a random > > picture id was returned is difficult/impossible and not worth it in > > general, so just ignore such buffers (they will have been already freed). > > > > Finally, mark all buffers as not in device after streamoff, and not only > > those that are known to be in client; V4L2 spec mandates that the device > > is to drop ownership of all queued buffers regardless of whether we dequeue > > them in this case. > > > > To test these situations: > > - enable the ResetBeforeDecode test for V4L2VDA; this tests for Reset()s > > before the Decode() with first config info is called; > > - add a new ResetAfterFirstConfigChange case to test situations where > > Reset() is called immediately after Decode() with first config info, which > > tests how VDA handles Reset() after it had a chance to request buffers, > > but before receiving them back. > > > > Also, fix ResetBeforeDecode test to work again, as it seems to have been > > accidentally broken by the recent refactoring. > > > > Finally, if a stream is shorter than kMaxResetAfterFrameNum, reset in the > > middle of it, instead of resetting after first frame arrives. > > > > BUG=319495,chrome-os-partner:21063 > > TEST=vdatest, MSE tests, seek tests, res switch tests, youtube with &t=1m > > R=fischman@chromium.org, sheu@chromium.org > > > > Review URL: https://codereview.chromium.org/151293003 > > TBR=posciak@chromium.org > > Review URL: https://codereview.chromium.org/137713009 TBR=posciak@chromium.org Review URL: https://codereview.chromium.org/150943007 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250560 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 248819 "V4L2VDA: Fix a few bugs related to Reset() and buf..."posciak@chromium.org2014-02-111-22/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > V4L2VDA: Fix a few bugs related to Reset() and buffer management. > > - If a Reset() arrived before the first Decode(), or, in general, if it > arrived before V4L2VDA requested buffers, it would assume it had already > have allocated buffers and go back to kDecoding before resuming. > > Fix this by checking if the buffers are allocated before resuming and go > back to kInitialized state, instead of kAfterReset. This only works because > we also now make buffer allocation an "atomic" operation for the decoder > thread (see below). > > - If a Reset() arrived after V4L2VDA had a chance to request buffers, but > before AssignPictureBuffers() and AssignPictureBuffersTask() resulted in > finishing the buffer allocation sequence, ResetTask would call > StopDevicePoll(), assume the buffers were good for reuse, and queue them to > the free output buffer queue. They would still be missing textures though > and not be ready for reuse, but the decoding would continue. Moreover, the > AssignPictureBuffersTask() would re-queue them to the free queue again. > > Fix this by simply making the decoder thread wait for AssignPictureBuffers > before continuing decoding. This doesn't have too much perf impact and > should solve some other potential corner cases, similar to the one above. > > With this, we don't need the AssignPictureBuffersTask anymore, and can > do everything in AssignPictureBuffers, while the decoder thread waits. > > Separately, don't bail out with an error in a situation when we've already > posted a DismissPictureBuffer for a PictureBuffer to the client and cleared > the corresponding metadata, but it has not yet executed in client before > it had a chance to post a ReusePictureBuffer for it back to us. > Verifying that this exact situation occurred however and not a random > picture id was returned is difficult/impossible and not worth it in > general, so just ignore such buffers (they will have been already freed). > > Finally, mark all buffers as not in device after streamoff, and not only > those that are known to be in client; V4L2 spec mandates that the device > is to drop ownership of all queued buffers regardless of whether we dequeue > them in this case. > > To test these situations: > - enable the ResetBeforeDecode test for V4L2VDA; this tests for Reset()s > before the Decode() with first config info is called; > - add a new ResetAfterFirstConfigChange case to test situations where > Reset() is called immediately after Decode() with first config info, which > tests how VDA handles Reset() after it had a chance to request buffers, > but before receiving them back. > > Also, fix ResetBeforeDecode test to work again, as it seems to have been > accidentally broken by the recent refactoring. > > Finally, if a stream is shorter than kMaxResetAfterFrameNum, reset in the > middle of it, instead of resetting after first frame arrives. > > BUG=319495,chrome-os-partner:21063 > TEST=vdatest, MSE tests, seek tests, res switch tests, youtube with &t=1m > R=fischman@chromium.org, sheu@chromium.org > > Review URL: https://codereview.chromium.org/151293003 TBR=posciak@chromium.org Review URL: https://codereview.chromium.org/137713009 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250553 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 247351 "IndexedDB: fsync after transactions."dgrogan@chromium.org2014-02-111-2/+4
| | | | | | | | | | | | | | | | | | | | > IndexedDB: fsync after transactions. > > IndexedDB corruption rose, only on CrOS, in the 32 release. Included in > that release was a change that stopped calling fsync after transactions > commit. It is the only IDB change that possibly sacrficed stability to get > better performance. So: revert it and see if corruption jumps back to 31 > levels. > > BUG=299831,338385 > > Review URL: https://codereview.chromium.org/137423006 TBR=dgrogan@chromium.org Review URL: https://codereview.chromium.org/147763011 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250468 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 249327 "Add PowerSaveBlocker in ContentVideoView"michaelbai@chromium.org2014-02-113-10/+88
| | | | | | | | | | | | | | | | | > Add PowerSaveBlocker in ContentVideoView > > This patch add additonal PowerSaveBlocker in ContentVideoView, and will block > screen sleep when ContentView's container isn't visiable. > > BUG=338873 > > Review URL: https://codereview.chromium.org/141553010 TBR=michaelbai@chromium.org Review URL: https://codereview.chromium.org/159543002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250307 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 250245 "Merge 249327 "Add PowerSaveBlocker in ContentVide..."michaelbai@chromium.org2014-02-113-92/+10
| | | | | | | | | | | | | | | | | | | | | | | > Merge 249327 "Add PowerSaveBlocker in ContentVideoView" > > > Add PowerSaveBlocker in ContentVideoView > > > > This patch add additonal PowerSaveBlocker in ContentVideoView, and will block > > screen sleep when ContentView's container isn't visiable. > > > > BUG=338873 > > > > Review URL: https://codereview.chromium.org/141553010 > > TBR=michaelbai@chromium.org > > Review URL: https://codereview.chromium.org/136443012 TBR=michaelbai@chromium.org Review URL: https://codereview.chromium.org/138913013 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250252 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 249327 "Add PowerSaveBlocker in ContentVideoView"michaelbai@chromium.org2014-02-113-10/+92
| | | | | | | | | | | | | | | | | > Add PowerSaveBlocker in ContentVideoView > > This patch add additonal PowerSaveBlocker in ContentVideoView, and will block > screen sleep when ContentView's container isn't visiable. > > BUG=338873 > > Review URL: https://codereview.chromium.org/141553010 TBR=michaelbai@chromium.org Review URL: https://codereview.chromium.org/136443012 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250245 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 247430 "Move net::RequestPriority to range-checked IPC ser..."inferno@chromium.org2014-02-101-1/+1
| | | | | | | | | | | | | | | | | | > Move net::RequestPriority to range-checked IPC serialization macros. > > The use of out-of-range net::RequestPriority values is being hit with > the IPC fuzzer, and is easy to fix. > > BUG=338532 > > Review URL: https://codereview.chromium.org/145583013 TBR=tsepez@chromium.org BUG=338532 Review URL: https://codereview.chromium.org/147723009 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250215 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 249763 "Fix the painting issue observed with windowed NPAP..."ananta@chromium.org2014-02-101-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | > Fix the painting issue observed with windowed NPAPI Flash plugins when we switch away from a tab which has an instance of > the plugin and switch back to it. > > When we switch back to the tab with the plugin, the flash RVHWA window becomes visible. The code which runs in the visible notification > handler runs through the plugin cutout rects calculation, which basically tries to remove areas where the plugin should not paint from its > clip region. In this case the cutout rects comes out as empty and the clip region in the plugin window moves structure is NULL. We end up > setting the window region to NULL which basically causes the plugin window to become useless. > > Fix is to not mess with the window region of the plugin if the cutout rects are empty. > > BUG=341564 > R=cpu@chromium.org, cpu > TBR=jam > > Review URL: https://codereview.chromium.org/140753008 TBR=ananta@chromium.org Review URL: https://codereview.chromium.org/159113002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250155 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 242553 "[Android] Send TapCancel if necessary when a touch..."mnaganov@chromium.org2014-02-102-6/+53
| | | | | | | | | | | | | | | | | | | > [Android] Send TapCancel if necessary when a touch gesture is consumed > > When a TouchStart is unconsumed by Javascript, a GestureTapDown is sent > immediately, potentially followed by a GestureShowPress. Fix the case where > the subsequent Touch{Move,End} is consumed by Javascript by synthesizing > a GestureTapCancel. > > BUG=330718 > > Review URL: https://codereview.chromium.org/120203003 TBR=jdduke@chromium.org Review URL: https://codereview.chromium.org/151803005 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250127 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 241402 "[Android] Suppress spurious ShowPress after a prev..."mnaganov@chromium.org2014-02-102-5/+69
| | | | | | | | | | | | | | | | | | | | | > [Android] Suppress spurious ShowPress after a preventDefault'ed touch > > Properly reset the GestureDetector if a touch sequence is preventDefault'ed > before it has turned into a movement gesture. This fixes the following problem > sequence: > 1) A touchstart is unconsumed by Javascript, and fed to the GestureDetector > 2) The next touchmove is preventDefault'ed, and not fed to the GestureDetector > 3) The ShowPress gesture timeout fires, as it never received a touchmove. > > BUG=328886 > > Review URL: https://codereview.chromium.org/105003009 TBR=jdduke@chromium.org Review URL: https://codereview.chromium.org/135503005 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250125 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 247941 "Fix fullscreen video race condition."cramya@chromium.org2014-02-103-7/+23
| | | | | | | | | | | | | | | | | > Fix fullscreen video race condition. > > A newly initialized media player must enter fullscreen if there is a > pending request sent by a previous media player. > > BUG=338670 > > Review URL: https://codereview.chromium.org/136113015 TBR=ohrn@opera.com Review URL: https://codereview.chromium.org/159053002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@250120 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 248442 "Fix bugs with renderer-side debug URLs, like chrom..."creis@chromium.org2014-02-077-18/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | > Fix bugs with renderer-side debug URLs, like chrome://crash or javascript:. > > These URLs should not cause a process swap when leaving pages like extensions > or view-source. Also, they should be ignored if the renderer process is not > live. > > BUG=335503 > BUG=334214 > TEST=chrome://kill works on extensions and is ignored on crashed tabs. > > Review URL: https://codereview.chromium.org/151593004 Also includes 249169 "Allow renderer debug URLs as initial navigations." https://codereview.chromium.org/147763010/ Updated for tests to compile on M33. R=nasko@chromium.org Review URL: https://codereview.chromium.org/153063006 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@249792 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 247744 "Make sure DeviceRequestMessageFilter call MediaStr..."niklase@chromium.org2014-02-061-2/+5
| | | | | | | | | | | | | | | | > Make sure DeviceRequestMessageFilter call MediaStreamManager::CancelRequest for all pending requests to MediaStreamManager::EnumerateDevices when the IPC channel is teared down. > > Before this change DeviceRequestMessageFilter call CancelRequest with the render process pid. But that pid was not been used as an identifier when calling EnumerateDevices. > > BUG=338561 > > Review URL: https://codereview.chromium.org/144363005 TBR=perkj@chromium.org Review URL: https://codereview.chromium.org/152543010 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@249452 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 249142 "[android_webview] Call onPageFinished for anchor n..."mkosiba@chromium.org2014-02-062-2/+18
| | | | | | | | | | | | | | | | | | | > [android_webview] Call onPageFinished for anchor navigations. > > This makes the android_webview call onPageFinished for navigations > which only result in the hash fragment being changed. This bug was > introduced when we switched from didStopLoading to didFinishLoad. > > BUG=341085, 291747 > > Review URL: https://codereview.chromium.org/139493008 BUG=341085 TBR=mkosiba@chromium.org Review URL: https://codereview.chromium.org/153173007 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@249413 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 249032 "Merge 248442 "Fix bugs with renderer-side debug U..."creis@chromium.org2014-02-057-97/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Didn't compile on M33. > Merge 248442 "Fix bugs with renderer-side debug URLs, like chrom..." > > > Fix bugs with renderer-side debug URLs, like chrome://crash or javascript:. > > > > These URLs should not cause a process swap when leaving pages like extensions > > or view-source. Also, they should be ignored if the renderer process is not > > live. > > > > BUG=335503 > > BUG=334214 > > TEST=chrome://kill works on extensions and is ignored on crashed tabs. > > > > Review URL: https://codereview.chromium.org/151593004 > > TBR=creis@chromium.org > > Review URL: https://codereview.chromium.org/150893003 TBR=creis@chromium.org Review URL: https://codereview.chromium.org/156003002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@249036 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 248442 "Fix bugs with renderer-side debug URLs, like chrom..."creis@chromium.org2014-02-057-18/+97
| | | | | | | | | | | | | | | | | | | | > Fix bugs with renderer-side debug URLs, like chrome://crash or javascript:. > > These URLs should not cause a process swap when leaving pages like extensions > or view-source. Also, they should be ignored if the renderer process is not > live. > > BUG=335503 > BUG=334214 > TEST=chrome://kill works on extensions and is ignored on crashed tabs. > > Review URL: https://codereview.chromium.org/151593004 TBR=creis@chromium.org Review URL: https://codereview.chromium.org/150893003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@249032 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 248586 "Probe whether MFPlat.dll is present on Windows sys..."scherkus@chromium.org2014-02-051-0/+8
| | | | | | | | | | | | | | | | > Probe whether MFPlat.dll is present on Windows systems. > > Not all versions of Windows 7 and later ship with Media Foundation DLLs. Instead of crashing while attempting to delay load the DLL, preemptively load the library and fail gracefully if we're unable to do so. > > BUG=339678 > > Review URL: https://codereview.chromium.org/151993002 TBR=scherkus@chromium.org Review URL: https://codereview.chromium.org/149113008 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@249020 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 247878 "android: Fix ContentViewCore and RenderWidgetHostV..."feng@chromium.org2014-02-042-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > android: Fix ContentViewCore and RenderWidgetHostViewAndroid lifetime issue > > https://codereview.chromium.org/26753005/ might have introduced crashes that > trace to SetContentViewCore. That previous patch assumed that ContentViewCore > (CVC) always outlives its associated RenderWidgetHostView. In this patch, we > are trying to ensure that the RWHVA pointer to CVC is nulled when CVC is > destroyed. > > Note the following: > - WebContents owns ContentViewCore and WebContentsView. > - CVC and WebContentsView are implicitly destroyed (no direct call to clean-up > code). So ContentViewCore cannot refer to WebContents or WebContentsView in > its destructor. > > Therefore, we use the observer of when WebContents is destroyed to start the > clean up on CVC. > > > BUG=335165, 324341 > > Review URL: https://codereview.chromium.org/133073012 TBR=powei@chromium.org Review URL: https://codereview.chromium.org/152763003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@248661 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 248007 "Expand the QuickTime quirk to handle all mime type..."jam@chromium.org2014-02-031-1/+3
| | | | | | | | | | | | | | | > Expand the QuickTime quirk to handle all mime types used by that plugin. > > BUG=308466 > R=ananta@chromium.org > > Review URL: https://codereview.chromium.org/150153002 TBR=jam@chromium.org Review URL: https://codereview.chromium.org/138003016 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@248565 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 247881 "Fix windowed plugins not appearing if opened in th..."jam@chromium.org2014-02-035-17/+31
| | | | | | | | | | | | | | | > Fix windowed plugins not appearing if opened in the background until the browser resizes. > > BUG=335900 > R=ben@chromium.org > > Review URL: https://codereview.chromium.org/150073002 TBR=jam@chromium.org Review URL: https://codereview.chromium.org/152913002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@248505 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 246446 "Add Windows Flash hw video decode trial."ihf@chromium.org2014-01-273-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | > Add Windows Flash hw video decode trial. > > This is to support the Windows rollout of the feature. > > The distribution on different channels will be controlled from the > server. Initially we will target 100% on canary/dev, 50% on beta and > starting slowly (say from 1%) on stable but this will be gradual and > is subject to approval. > > Also remove low latency audio trail which has expired a long time ago. > (It also is hard wired to enabled in all Flash binaries.) > > BUG=chromium:335836 > TEST=Verified Flash flags are properly passed on Link. > > Review URL: https://codereview.chromium.org/141753006 TBR=ihf@chromium.org Review URL: https://codereview.chromium.org/132333013 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@247307 0039d316-1c4b-4281-b951-d872f2087c98
* Merge r246820 manually to 1750scottmg@chromium.org2014-01-271-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was a reapplication of r246820 manually due to things moving around since the M33 branch. --- Force software for menus to work around corruption in classic This occurs only in the particular circumstances of running in Classic mode, using the GPU rendering path in Chrome, and opening the menu on a secondary monitor. It appears to be that when the mouse is moved the contents of the GDI DC are redrawn by Windows, rather than the surface that was presented by the D3D path. To workaround this problem, force the menu to software compositing. This should be faster than rendering in gpu and doing a readback to draw on to the GDI surface). (This is to be merged potentially all the way back to 32.) --- TBR=scottmg@chromium.org BUG=333380 Review URL: https://codereview.chromium.org/148443003 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@247281 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 246517 "Make sure that each NSWindow has its own GL context"ccameron@chromium.org2014-01-241-17/+27
| | | | | | | | | | | | | | | | | | | | | | | > Make sure that each NSWindow has its own GL context > > Update the GL context for an NSView before drawing it, in > CreateCompositedIOSurface. > > In the case of the devtools window being added and removed, > the WindowFrameChanged is not called on the devtools window, > and as a result, it and the main window compete for the same > context (which sometimes results in nothing being drawn for > the devtools window). > > BUG=335011 > > Review URL: https://codereview.chromium.org/140693013 TBR=ccameron@chromium.org Review URL: https://codereview.chromium.org/145083014 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246943 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 246442 "Unbind GL context from the overlay NSView"ccameron@chromium.org2014-01-231-1/+7
| | | | | | | | | | | | | | | | | | | | | | > Unbind GL context from the overlay NSView > > When drawing an overlay NSView, the underlay will draw both > itself and the overlay. Leaving the GL context bound to the > overlay NSView can result in visual corruption (the desktop being > seen through where the overlay NSView is). > > By unbinding the NSView, only the transparent window remains, > through which the underlay can be seen. > > BUG=330701 > > Review URL: https://codereview.chromium.org/142083003 TBR=ccameron@chromium.org Review URL: https://codereview.chromium.org/145263004 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246681 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 246398 "Android: fix rotation vector exception on some Sam..."timvolodine@chromium.org2014-01-231-1/+16
| | | | | | | | | | | | | | | | | | | | | > Android: fix rotation vector exception on some Samsung devices. > > On some Samsung devices (e.g. Galaxy Note 3 and Galaxy S4) the > SensorManager.getRotationMatrixFromVector() appears to throw an > exception when the passed rotation vector has length > 4. > To fix this a truncated version of the rotation vector is passed > to getRotationMatrixFromVector(). There is no loss of information > as the latter method only uses the first 4 elements anyway. > > BUG=335298 > > Review URL: https://codereview.chromium.org/143993010 TBR=timvolodine@chromium.org Review URL: https://codereview.chromium.org/145033009 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246639 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 246077 "Fix bug where GL fence objects were shared between..."ccameron@chromium.org2014-01-224-58/+59
| | | | | | | | | | | | | | | | | | | | | | | | > Fix bug where GL fence objects were shared between contexts. > > These objects were allocated during DrawIOSurface when copying > the IOSurface to a video frame. > > This pulls the copy to the video frame up to CompositorSwapBuffers, > and performs the copy in a separate context. Using the separate > context makes a call to glFlush before the copy necessary (to be sure > that the copy gets the correct contents), and after, to kick off the async > copy. > > Moving the copy up to the swap make it so that we won't send more > frames just because of window damage. > > BUG=334742 > > Review URL: https://codereview.chromium.org/137893022 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246451 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 241431 "Work around Mac OS 10.9 window server synchronizat..."ccameron@chromium.org2014-01-221-3/+6
| | | | | | | | | | | | | | | | | | | | > Work around Mac OS 10.9 window server synchronization bug. > > When using the integrated GPU with multiple windows open, the display > will shudder and flicker. It appears that the front and back buffers > are fighting to be displayed (sometimes the previous frame is shown, > sometimes the new frame is shown). When a glFinish is added here, the > bug goes away. > > BUG=318877 > > Review URL: https://codereview.chromium.org/103943011 TBR=ccameron@chromium.org Review URL: https://codereview.chromium.org/145083004 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246400 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 246203 "Fix a regression that some audio will pause after ..."qinmin@chromium.org2014-01-221-2/+10
| | | | | | | | | | | | | | | | | | | | > Fix a regression that some audio will pause after chrome switch to background > > Because an android issue that MediaPlayer will report size(0, 0) on some video streams initially, our previous change doesn't take a stream as audio only even if its size is empty. > This caused the chrome to pause some of the audio stream if they are mistreated as video. > This patch reverts the previous change. Instead, we changed the logic to call EstablishSurfaceTexturePeer() lazily when size information gets finally reported by the android MediaPlayer. We need to call this because we may have missed the call when play() gets called. > > Tried the patch with the links in crbug/313774, and it works fine now. > > BUG=336479 > > Review URL: https://codereview.chromium.org/138123008 TBR=qinmin@chromium.org Review URL: https://codereview.chromium.org/145163002 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246397 0039d316-1c4b-4281-b951-d872f2087c98
* Fix broken AEC dump.grunell@chromium.org2014-01-221-0/+2
| | | | | | | | | | | | | | | - Change libjingle deps to 3.48 branch. (Reverts the changed way of enabling AEC dump.) - Enable AEC dump if command line flag is set. (Revert content/renderer/media/media_stream_dependency_factory.cc change from the webrtc roll in http://crrev.com/241095.) Depends on https://webrtc-codereview.appspot.com/7399004/ TBR=tommi@chromium.org BUG=336171 Review URL: https://codereview.chromium.org/138163005 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246308 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 245992 "Validate vector lengths in ImageHostMsg_DidDownloa..."dharani@google.com2014-01-221-0/+3
| | | | | | | | | | | | | | > Validate vector lengths in ImageHostMsg_DidDownloadImage > TBR=sky@chromium.org > BUG=333038 > > Review URL: https://codereview.chromium.org/136853008 TBR=ianbeer@chromium.org Review URL: https://codereview.chromium.org/141003010 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246177 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 245949 "Add more non client Windows messages to the list o..."ananta@chromium.org2014-01-211-0/+9
| | | | | | | | | | | | | | | | | | | > Add more non client Windows messages to the list of messages not being sent to the renderer. > > Turns out we get WM_NCLBUTTONDOWN/UP messages at times which go to the renderer and are not acked causing the > unresponsive renderer dialog to show up in Desktop Chrome Aura. > > BUG=335248 > R=jam@chromium.org > TBR=jam > > Review URL: https://codereview.chromium.org/141103004 TBR=ananta@chromium.org Review URL: https://codereview.chromium.org/144093006 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246172 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 245948 "Correctly handle NULL ResourceDispatcherHostImpl::..."piman@chromium.org2014-01-211-4/+9
| | | | | | | | | | | | | | | | | | | > Correctly handle NULL ResourceDispatcherHostImpl::scheduler() > > During shutdown, the ResourceDispatcherHost has cleared its scheduler after it > stops handling renderer requests. However there may still be renderers alive at > this point, and messages in their pipes, so make sure handling these messages > don't try to access the destroyed ResourceScheduler. > > BUG=335578 > > Review URL: https://codereview.chromium.org/142133002 TBR=piman@chromium.org Review URL: https://codereview.chromium.org/144383004 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246161 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 245723 "Ensure touch handler state on Android is accurate ..."rbyers@chromium.org2014-01-212-11/+18
| | | | | | | | | | | | | | | | | | | | > Ensure touch handler state on Android is accurate after preload > > In preload scenarios, ContentViewCore is attached to RenderWidgetHostViewAndroid when the contents becomes visible - long after the page was loaded as JS has been run. If that JS registered a touch event handler, then ContentViewCore won't be notified of it, and future touch events will be dropped on the floor. > > Fix this by sending the current touch handler state to ContentViewCore when it's attached. This required moving the initialization of ContentViewGestureHandler (and related pieces) slightly earlier. > > This fix is intentionally minimal to lower the merge risk. A more complete fix would be to stop worrying about the touch handler state up in java at all - leave it all to the common code in InputRouter (which is already relied upon for Aura). We will get this essentially for free as part of http://crbug.com/332418. > > BUG=332961 > > Review URL: https://codereview.chromium.org/140833005 TBR=rbyers@chromium.org Review URL: https://codereview.chromium.org/129873013 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246159 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 245174 "A misplaced break statement is screwing up Downloa..."felt@chromium.org2014-01-211-1/+1
| | | | | | | | | | | | | | > A misplaced break statement is screwing up Download.DangerousFile.Discard > > BUG=333309 > > Review URL: https://codereview.chromium.org/138613003 TBR=felt@chromium.org Review URL: https://codereview.chromium.org/137273007 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246158 0039d316-1c4b-4281-b951-d872f2087c98
* Merge 244774 "Add UMA metric for all malicious download warnings"felt@chromium.org2014-01-213-0/+21
| | | | | | | | | | | | | | | | > Add UMA metric for all malicious download warnings > > This adds Download.MaliciousDownloadClassified, which should count all of the downloads that are labelled with one of the malicious download warnings. Each download should be recorded precisely once. > > BUG=333309 > > Review URL: https://codereview.chromium.org/137283002 TBR=felt@chromium.org Review URL: https://codereview.chromium.org/134733013 git-svn-id: svn://svn.chromium.org/chrome/branches/1750/src@246153 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-04 10:49:10 +0000