Empty blocks in the "Sync Protocol Log" section on chrome://sync-internals |
||
Issue description(I initially repor'd it on my Linux build, but can repro on the latest Canary on Windows also.) Google Chrome 63.0.3215.0 (Developer Build) unknown (64-bit) Revision 0236c0f032dbc337ffb2f0f33a28a9ec442b3154- OS Linux JavaScript V8 6.3.135 User Agent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3215.0 Safari/537.36 Command Line ./out/gn_out/chrome --user-data-dir=/tmp/profile --enable-logging --enable-features=SafeBrowsingV4OnlyEnabled,PermissionsBlacklist,SyncPasswordReuseEvent --vmodule=v4_*=1,database_manager*=1,*permission*=1,*password*=1,*event*=1 --flag-switches-begin --flag-switches-end http://testsafebrowsing.appspot.com/ I have been noticing this since yesterday. What steps will reproduce the problem? (1) Open chrome://sync-internals. (2) Trigger a SyncPasswordReuseEvent event (3) Observe the Sync Protocol Log section What is the expected result? Blocks are not empty, they contain user event and other information. What happens instead? Large empty blocks. See attached photo.
,
Sep 14 2017
The data shows correctly on the 'Traffic Log' tab so that's a workaround. I suspect this is some JS misbehaving.
,
Sep 14 2017
I can also confirm that the dom element exists, as expected:
<pre class="proto traffic-event-entry-expanded" jscontent="JSON.stringify(proto, null, 2)" jstcache="5">{
...
}</pre>
,
Sep 14 2017
On my machine, the first 3 entries in the Protocol Log had data, but the rest were blank. I'm glad you found the Traffic Log, and it's still working. Actually seems that the CL that created the Traffic Log tab may be to blame here. Reverting https://chromium-review.googlesource.com/c/chromium/src/+/619762 seems to fix the Protocol Log.
,
Sep 14 2017
If you expand something like the 4th or 5th entry, and then use the Protocol Log's scroll bar, you can actually see a sliding white cutoff that's moving over the contents. As pointed out in c#3, the content is there, just hidden.
,
Sep 14 2017
I was wrong in c#4 blaming https://chromium-review.googlesource.com/c/chromium/src/+/619762 was incorrect, it still repros with that change reverted.
,
Sep 14 2017
Trying to bisect, it would seem that 63.0.3211.0 was healthy, and 63.0.3212.0 appears to be broken. It also crashes constantly, seemingly being crbug.com/750500 . Not sure how that affects the clipping problems...
,
Sep 14 2017
Looks like https://chromium.googlesource.com/chromium/src/+/c3a3481c4b1b08775b477144d1d2873a2a3d9900 broke us. I think we may be a dupe of issue 764259 |
||
►
Sign in to add a comment |
||
Comment 1 by s...@chromium.org
, Sep 14 2017