Send microsecond resolution timestamps to Java history page so they can be sent back.

Send microsecond resolution timestamps to Java history page so they can be sent back.

When an entry on the history page is deleted, we create history
deletion directives that are sent through sync. These are required to
support offline history deletions, and make sure these are properly
propagated. However, these deletion directives rely on exact matches in
timestamps, which are in microseconds since the epoch.

The History page on Android converted microsecond timestamps to
millisecond timestamps for Java compatibility, but when these
timestamps were handed to the logic that created history deletion
directives, they were now slightly off. This change simply plumbs
through microsecond timestamps through the java code and back.

BUG=729020
Review-Url: https://codereview.chromium.org/2935783002
Cr-Commit-Position: refs/heads/master@{#478756}
Committed: https://chromium.googlesource.com/chromium/src/+/209633050f6d05fff54e8dcd2195743858b33125

[skym, 2017-06-12 17:39:26]

Description was changed from

==========
Send microsecond resolution timestamps to Java history page so they can be sent
back.

BUG=729020
==========

to

==========
Send microsecond resolution timestamps to Java history page so they can be sent
back.

When an entry on the history page is deleted, we create history
deletion directives that are sent through sync. These are required to
support offline history deletions, and make sure these are properly
propagated. However, these deletion directives rely on exact matches in
timestamps, which are in microseconds since the epoch.

The History page on Android converted microsecond timestamps to
millisecond timestamps for Java compatibility, but when these
timestamps were handed to the logic that created history deletion
directives, they were now slightly off. This change simply plumbs
through microsecond timestamps through the java code and back.

BUG=729020
==========

[skym, 2017-06-12 17:39:26]

skym@chromium.org changed reviewers:
+ twellington@chromium.org

[skym, 2017-06-12 17:39:32]

The CQ bit was checked by skym@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-12 17:40:00]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[skym, 2017-06-12 17:40:57]

PTAL

[commit-bot: I haz the power, 2017-06-12 18:07:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-12 18:07:29]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Theresa, 2017-06-12 18:23:21]

https://codereview.chromium.org/2935783002/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/history/HistoryItem.java
(right):

https://codereview.chromium.org/2935783002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/history/HistoryItem.java:37:
long[] nativeTimestamps, boolean blockedVisit) {
history/StubbedHistoryProvider.java and history/BrowsingHistoryBridge.java
construct HistoryItems, so those classes needs to be updated.

https://codereview.chromium.org/2935783002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/history/HistoryItem.java:48:
mLastJavaTimestamp = mJavaTimestampList[mJavaTimestampList.length - 1];
I think we can remove mJavaTimestampList and make this line:

mLastJavaTimestamp = javaTimestamps[javaTimestamps.legnth - 1];


Perhaps instead of passing back an entire Java timestamps array, native could
just pass the last timestamp.

https://codereview.chromium.org/2935783002/diff/1/chrome/browser/android/hist...
File chrome/browser/android/history/browsing_history_bridge.cc (left):

https://codereview.chromium.org/2935783002/diff/1/chrome/browser/android/hist...
chrome/browser/android/history/browsing_history_bridge.cc:117:
timestamps.clear();
I had added this to make sure int64 timestamps in the vector didn't hang around
in memory unnecessarily, but perhaps the call isn't really doing anything?

[skym, 2017-06-12 19:44:42]

The CQ bit was checked by skym@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-12 19:45:09]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[skym, 2017-06-12 19:45:13]

Updates for twellington@

https://codereview.chromium.org/2935783002/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/history/HistoryItem.java
(right):

https://codereview.chromium.org/2935783002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/history/HistoryItem.java:37:
long[] nativeTimestamps, boolean blockedVisit) {
On 2017/06/12 18:23:21, Theresa wrote:
> history/StubbedHistoryProvider.java and history/BrowsingHistoryBridge.java
> construct HistoryItems, so those classes needs to be updated.

Whoops, that explains the failing bots! Done.

https://codereview.chromium.org/2935783002/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/history/HistoryItem.java:48:
mLastJavaTimestamp = mJavaTimestampList[mJavaTimestampList.length - 1];
On 2017/06/12 18:23:21, Theresa wrote:
> I think we can remove mJavaTimestampList and make this line:
> 
> mLastJavaTimestamp = javaTimestamps[javaTimestamps.legnth - 1];
> 
> 
> Perhaps instead of passing back an entire Java timestamps array, native could
> just pass the last timestamp.

Done.

https://codereview.chromium.org/2935783002/diff/1/chrome/browser/android/hist...
File chrome/browser/android/history/browsing_history_bridge.cc (left):

https://codereview.chromium.org/2935783002/diff/1/chrome/browser/android/hist...
chrome/browser/android/history/browsing_history_bridge.cc:117:
timestamps.clear();
On 2017/06/12 18:23:21, Theresa wrote:
> I had added this to make sure int64 timestamps in the vector didn't hang
around
> in memory unnecessarily, but perhaps the call isn't really doing anything?

Yeah, I don't think it was needed. The vector |timestamps| is going to be
destroyed as soon as we leave the current scope, which is the '}' below. I don't
really know what it does in its destructor, but I don't think that's something
we need to worry about.

[Theresa, 2017-06-12 20:03:58]

lgtm

Thank you for making this change!

[commit-bot: I haz the power, 2017-06-12 20:48:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-12 20:48:04]

Dry run: This issue passed the CQ dry run.

[skym, 2017-06-12 20:48:44]

The CQ bit was checked by skym@chromium.org

[commit-bot: I haz the power, 2017-06-12 20:49:34]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-12 20:55:08]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1497300524605250,
"parent_rev": "61856d2266ce3b76ac8485a9ad2091d18842472a", "commit_rev":
"209633050f6d05fff54e8dcd2195743858b33125"}

[commit-bot: I haz the power, 2017-06-12 20:55:18]

Description was changed from

==========
Send microsecond resolution timestamps to Java history page so they can be sent
back.

When an entry on the history page is deleted, we create history
deletion directives that are sent through sync. These are required to
support offline history deletions, and make sure these are properly
propagated. However, these deletion directives rely on exact matches in
timestamps, which are in microseconds since the epoch.

The History page on Android converted microsecond timestamps to
millisecond timestamps for Java compatibility, but when these
timestamps were handed to the logic that created history deletion
directives, they were now slightly off. This change simply plumbs
through microsecond timestamps through the java code and back.

BUG=729020
==========

to

==========
Send microsecond resolution timestamps to Java history page so they can be sent
back.

When an entry on the history page is deleted, we create history
deletion directives that are sent through sync. These are required to
support offline history deletions, and make sure these are properly
propagated. However, these deletion directives rely on exact matches in
timestamps, which are in microseconds since the epoch.

The History page on Android converted microsecond timestamps to
millisecond timestamps for Java compatibility, but when these
timestamps were handed to the logic that created history deletion
directives, they were now slightly off. This change simply plumbs
through microsecond timestamps through the java code and back.

BUG=729020

Review-Url: https://codereview.chromium.org/2935783002
Cr-Commit-Position: refs/heads/master@{#478756}
Committed:
https://chromium.googlesource.com/chromium/src/+/209633050f6d05fff54e8dcd2195...
==========

[commit-bot: I haz the power, 2017-06-12 20:55:19]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/209633050f6d05fff54e8dcd2195...