Chromium

Changelog between the mentioned r547707 snapshot and the next r547715:
https://chromium.googlesource.com/chromium/src/+log/7500cac..cc4fa433

Suspecting r547712 = 51f305bf770e7a958a02b46d16357e497307e81f
"[signin] Update fieldtrial_testing_config for Dice Milestone 2"

Tested now with
Chromium        67.0.3390.0 (Versão do desenvolvedor) 64 bits
Revisão 1c1627f7a35299d6aa99413a348586508d9a34f3-refs/heads/master@{#548363}
SO      Linux

Same issue persist on Linux_x64

Now back to
Chromium        67.0.3388.0 (Versão do desenvolvedor) 64 bits
Revisão 12f07f347ef3da775c67e86ddcf67e3249c6b396-refs/heads/master@{#547709}
SO      Linux

Working normal with this snapshot.....

Something has be modified after 547709 that affect and persist even in 548663 on Linux_x64

Win_X64 samething except builds involved that 547707 is the last that not be affected

All snaps taken from https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html

Tested again with Linux_X64 revision 548399 and Win_X64 revision 548397.....
Still the issue....
Tested on vm with clean installations......

Linux_X64 revision 547709 and Win_X64 revision 547707 are the last that don't have this issue.....

[Empty comment from Monorail migration]

Occurring here with Gmail. Tripping an unknown error. Screenshot attached.

Chromium 67.0.3390.0 (Official Build) (64-bit)
Revision e8f2c03b9993edbf20c66dfaaca06cb7426fde33-refs/heads/master@{#548304}
Linker lld-link

[Comment Deleted]

Delete comment ⚐
Exactly what happened after revision 547707 on Win_X64 and 547709 on Linux_X64

I have tested now this time only in Linux (busy now) with samething issue still happening

Chromium        67.0.3390.0 (Versão do desenvolvedor) 64 bits
Revision        97f56ecee368ae726e6117c8962f09cf2311608e-refs/heads/master@{#548628}
SO      Linux

It occurs everytime you try login in Google services (GMail, GDrive, Youtube, etc.....)

Issue persists. Did a local build to verify.

Chromium 67.0.3391.0 (Official Build) (64-bit)
Revision 0c9503aa28aae7820afc878edc62d588a3966e1d-refs/heads/master@{#548680}
OS Windows

Still happening......


Chromium        67.0.3391.0 (Versão do desenvolvedor) 64 bits
Revisão 3007e94ba76a8321a6d621ee8858f8b85ee53864-refs/heads/master@{#548751}
SO      Linux

Last know working revision:

Chromium        65.0.3325.181 (Versão oficial) Built on Ubuntu , running on Ubuntu 18.04 64 bits
Revisão abb5172872b726072a64dfabaf45894c6ecf7369-
SO      Linux

[Comment Deleted]

Issue persists.

Chromium        67.0.3391.0 (Versão do desenvolvedor) 64 bits
Revisão ded21b7408ac7d9fc075e81f16a39702e50459e4-refs/heads/master@{#548830}
SO      Linux
JavaScript      V8 6.7.241
Flash   29.0.0.134 /usr/lib/adobe-flashplugin/libpepflashplayer.so

Last know working revision:


Chromium        67.0.3388.0 (Versão do desenvolvedor) 64 bits
Revisão 12f07f347ef3da775c67e86ddcf67e3249c6b396-refs/heads/master@{#547709}
SO      Linux
JavaScript      V8 6.7.213
Flash   29.0.0.134 /usr/lib/adobe-flashplugin/libpepflashplayer.so

Last know working revision:


Chromium        67.0.3388.0 (Versão do desenvolvedor) 64 bits
Revisão 7500cac5b54bd0cbf2f7cb990ba11fcea1f4c72b-refs/heads/master@{#547707}
SO      Windows
JavaScript      V8 6.7.213
Flash   29.0.0.147 C:\Windows\system32\Macromed\Flash\pepflashplayer64_29_0_0_147.dll

Issue persists.

Chromium        67.0.3391.0 (Versão do desenvolvedor) 64 bits
Revisão 92a1603f408da31134838379b7fc7933245b553c-refs/heads/master@{#548819}
SO      Windows
JavaScript      V8 6.7.241
Flash   29.0.0.147 C:\Windows\system32\Macromed\Flash\pepflashplayer64_29_0_0_147.dll

Still the issue but this time a different page is open (attached)

Chromium        67.0.3391.0 (Versão do desenvolvedor) 64 bits
Revisão 54ecc45c405bab77c3b082015107806aa8c80b9e-refs/heads/master@{#548916}
SO      Linux
JavaScript      V8 6.7.241
Flash   29.0.0.147 /usr/lib/adobe-flashplugin/libpepflashplayer.so


Last know good revision


Chromium        67.0.3388.0 (Versão do desenvolvedor) 64 bits
Revisão 12f07f347ef3da775c67e86ddcf67e3249c6b396-refs/heads/master@{#547709}
SO      Linux
JavaScript      V8 6.7.213
Flash   29.0.0.147 /usr/lib/adobe-flashplugin/libpepflashplayer.so

Update. I did a revert 51f305bf770e7a958a02b46d16357e497307e81f on a local build. Did not help with the issue.

Now getting the 500 error now as well. Once at the 500 error page, click the back button, and Gmail finally loads - at least here.

Let's see if I get it right.
Did you get the revision sources 5747712 and compiled locally?
Is my interpretation correct?
Did you make any changes to the source code if you've recompiled it?
Or did you simply throw the binaries of this review on your local installation?

Update!

Now I have tested revision with description below in a not clean user data and same screen error appears but when I click on back one time to reload the user name login and click on the username it redirects and load the webmail content apparently with no issues. But still present the error page at first time.


Chromium        67.0.3391.0 (Versão do desenvolvedor) 64 bits
Revisão 413bd463287b732ce9971b8f96b35be21109bceb-refs/heads/master@{#548993}
SO      Linux
JavaScript      V8 6.7.242
Flash   29.0.0.147 /usr/lib/adobe-flashplugin/libpepflashplayer.so
Agente do usuário       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3391.0 Safari/537.36

Last known revision without any issue


Chromium        67.0.3388.0 (Versão do desenvolvedor) 64 bits
Revisão 12f07f347ef3da775c67e86ddcf67e3249c6b396-refs/heads/master@{#547709}
SO      Linux
JavaScript      V8 6.7.213
Flash   29.0.0.147 /usr/lib/adobe-flashplugin/libpepflashplayer.so

I have done same test above but in a clean user data and happens this:
1-typed mail.google.com
2-appears the login and I fill with the e-mail name account
3-next screen fill with the password
3-browser show the error page(attached)
4-click on the back icon and reload and go to the web mail account apparently with no issues.

Difference what occurs above is that I have more than one gmail account and because that chromium showme again the e-mail account selection.
In this test had no data before.

But still an issue or bug.

[Empty comment from Monorail migration]

Have tested in Win_X64 environment.
Same description what happened with the Linux Version above.
When the browser shows the ERR 500 page click once on the back icon then it reload and run directly to the webmail content.
If have more than one e-mail account that had entered it show them to choose again but not require the password again if are the same if the previous atteempt.

Here goes the info:

Chromium        67.0.3391.0 (Versão do desenvolvedor) 64 bits
Revisão 945649e072ac3d12c7735cae4e4aef76756117de-refs/heads/master@{#548991}
SO      Windows
JavaScript      V8 6.7.242
Flash   29.0.0.147 C:\Windows\system32\Macromed\Flash\pepflashplayer64_29_0_0_147.dll
Agente do usuário       Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3391.0 Safari/537.36

The last know good revision:



Chromium        67.0.3388.0 (Versão do desenvolvedor) 64 bits
Revisão 7500cac5b54bd0cbf2f7cb990ba11fcea1f4c72b-refs/heads/master@{#547707}
SO      Windows
JavaScript      V8 6.7.213
Flash   29.0.0.147 C:\Windows\system32\Macromed\Flash\pepflashplayer64_29_0_0_147.dll

I've done some testing here by logging into 3 different email accounts in GMail but there's something that leaves me baffled.
In this procedure (temporary I hope) to return a screen and choose again which user, if you keep going back screens I tried to see if by chance he would have registered the logout of the previous session or if I would eventually enter a previous session of another account without typing password.
As two accounts I have use the same password I was in doubt and put a third.
Apparently there was no interference and the system was not lost or confused but there is perhaps a potential breach here until all of this is healed.
Luckily it's a development version.

@https://crbug.com/chromium/829220#c15 I compile my own Chromium builds. I reverted the indicated commit with no change.

----------------

Given it is a HTTP 500 server error being experienced, I have cross posted an error report to the Gmail support forum as well.

https://productforums.google.com/forum/#!topic/gmail/KsMA6hbCy04;context-place=forum/gmail

[Comment Deleted]

Still ongoing as of 67.0.3393.0-r549357.

Exactly the same problem here.

Adding the conops hotlist as we've seen this reported in the Gmail community:

- https://productforums.google.com/forum/#!topic/gmail/KsMA6hbCy04

I started this problem report 5 days ago, but in taking into consideration that revision 547709 was released 7 days ago .....

It is frustrating to see that an account of a failure that may even be exploited and allow access to user data such as password and GMail account has so little attention.

I am an end user and I am doing this without even being part of any team or volunteer.
I do it because I know the consequences and I know that from the Chromium project a myriad of browsers use the same engine.


When I go to the GMail community and see the report of this bug put there and come a user that for some reason has relevant participation, although it does not respond by the company Google to say that Chromium is not a compatible browser and that the report has no significance reminds me of the same report in the Ubuntu ppa curl program where they made changes in dependencies that caused that in Ubuntu systems installed several programs were removed and wash their hands saying that it was not their problem when in fact it was due to the modification that they did without before test the impact on the system and other installed programs were Canonical or not .....

Luckily, until now we do not have any psychopath hackers to the point of paying attention to everything that has already made use of flaws like this and causing confusion on a global scale.

But one day luck ends ......
But as it is always the policy "users who come alone" and ark with the consequences of the irresponsibilities of others ......

SO Linux_X64

Chromium        67.0.3394.0 (Versão do desenvolvedor) 64 bits
Revisão c7867ebdfb9d6a4d9233dd4be363cd291a6bc6aa-refs/heads/master@{#549649}
SO      Linux
JavaScript      V8 6.7.271
Flash   29.0.0.147 /usr/lib/adobe-flashplugin/libpepflashplayer.so


Last known revision without any issue


Chromium        67.0.3388.0 (Versão do desenvolvedor) 64 bits
Revisão 12f07f347ef3da775c67e86ddcf67e3249c6b396-refs/heads/master@{#547709}
SO      Linux
JavaScript      V8 6.7.213
Flash   29.0.0.147 /usr/lib/adobe-flashplugin/libpepflashplayer.so

Able to reproduce the issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Chromium build 64.0.3395.0 (revision- 549853)

Bisect Information:
====================
Good Build : 67.0.3388.0 - revision number: 547709
Bad Build :  67.0.3388.0 - revision number: 547715

As per https://crbug.com/chromium/829220#c1, Below is the Changelog URL
https://chromium.googlesource.com/chromium/src/+log/7500cac..cc4fa433

From the above Changelog, Suspecting the below Change
Reviewed-on: https://chromium-review.googlesource.com/975561

droger@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Thanks..

[Monorail components: Services>SignIn]

My change is indeed probably related, however there might be several different problems going on there. Because my change should not impact facebook login in theory.

Can you please try the following, on a recent build that exhibits the problem:
1) Go to chrome://flags/#account-consistency and change the value to "Enabled Dice (fix auth errors)". Check if both issues persist (Google and Facebook), and report the results.
2) Set the value to "Enabled Dice (prepare migration, Chrome sync endpoint)" and check again.

For Google websites, if the login works with 2) but not 1), then this is indeed caused by that CL.

I would be surprised if that CL broke Facebook though, but we'll see.

I would not be surprised if it breaks Google login though, and if it is confirmed, then the fix is probably to rebuild Chrome with a Sync API key (probably using the instructions here https://www.chromium.org/developers/how-tos/api-keys).

[Empty comment from Monorail migration]

As far as Gmail is concerned....

'Enabled Dice (fix auth errors)' = login works

'Enabled Dice (prepare migration, Chrome sync endpoint)' = HTTP 500 error

...on locally built 67.0.3394.0-r549717.

^For verify for clarification, I do not build with API keys.

login works direct with Enable Dice (fix auth errors)
login show HTTP 500 error and need click on back icon one time to login with Enabled Dice (prepare migration, Chrome sync endpoint)
login not work with others options

All these tested only in Linux_x64 as follow:

Chromium        67.0.3395.0 (Versão do desenvolvedor) 64 bits
Revisão 76ab6dc58df5d79eea87411d2c7cf7f1b194e132-refs/heads/master@{#549996}
SO      Linux
JavaScript      V8 6.7.287
Flash   29.0.0.147 /usr/lib/adobe-flashplugin/libpepflashplayer.so

Thank you, and sorry for the inconvenience.

I'm going to undo my change for now, this should fix the problem.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8cb55171dddde570257127a055132b9ad8fed284

commit 8cb55171dddde570257127a055132b9ad8fed284
Author: David Roger <droger@chromium.org>
Date: Fri Apr 13 13:21:44 2018

[signin] Revert Dice default testing config to Milestone 1

Dice Milestone 2 was enabled by default in CL:
https://chromium-review.googlesource.com/c/chromium/src/+/975561

However this is causing issues when signing into Google properties on
the web, because the new server endpoint rejects most of the client IDs.

This restores the previous behavior.

Bug: 829220
TBR: jwd
Change-Id: I3d7c22cb10f0d900c8d897369b063ac236f12146
Reviewed-on: https://chromium-review.googlesource.com/1011620
Commit-Queue: David Roger <droger@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550607}
[modify] https://crrev.com/8cb55171dddde570257127a055132b9ad8fed284/testing/variations/fieldtrial_testing_config.json

[Empty comment from Monorail migration]

All tests performed in a not clean session with multiple GMail accounts with different value set on chrome://flags/#account-consistency and all of them specifically attempts to login in mail.google.com

1-Set the value to "Disable" works fine
2-Set the value to "Default" works fine
3-Set the value to "Enable" works fine
4-Set the value to "Enable Dice" HTTP 500 Error and click on back icon to      relogin don't work ass still go to HTTP 500 error page
5-Set the value to "Enable Dice (migration)" HTTP 500 Error and click on back icon to relogin don't work ass still go to HTTP 500 error page
6-Set the value to "Enable Dice (prepare migration, Chrome sync endpoint) HTTP 500 error page but click on back icon and goto directly to webmail
7-Set the value to "Enable Dice (fix auth errors)" works fine


Chromium        68.0.3397.0 (Versão do desenvolvedor) 64 bits
Revisão 41bb3451f6aacd0969b87ef30701ed9410d399db-refs/heads/master@{#550620}
SO      Linux
JavaScript      V8 6.7.288.1
Flash   29.0.0.147 /usr/lib/adobe-flashplugin/libpepflashplayer.so

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8cb55171dddde570257127a055132b9ad8fed284

commit 8cb55171dddde570257127a055132b9ad8fed284
Author: David Roger <droger@chromium.org>
Date: Fri Apr 13 13:21:44 2018

[signin] Revert Dice default testing config to Milestone 1

Dice Milestone 2 was enabled by default in CL:
https://chromium-review.googlesource.com/c/chromium/src/+/975561

However this is causing issues when signing into Google properties on
the web, because the new server endpoint rejects most of the client IDs.

This restores the previous behavior.

Bug: 829220
TBR: jwd
Change-Id: I3d7c22cb10f0d900c8d897369b063ac236f12146
Reviewed-on: https://chromium-review.googlesource.com/1011620
Commit-Queue: David Roger <droger@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550607}
[modify] https://crrev.com/8cb55171dddde570257127a055132b9ad8fed284/testing/variations/fieldtrial_testing_config.json

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/de95b29a55c944b2540c43353de3201d7cb7de0f

commit de95b29a55c944b2540c43353de3201d7cb7de0f
Author: Mihai Sardarescu <msarda@chromium.org>
Date: Fri May 04 15:07:31 2018

[dice] Enable Desktop Identity Consistency M2 for tests

This CL enables Dice M2 by default in Chromium that have API keys
configured as those are mandatory for DICE.

It also ensures that unit and browser tests have DICE M2 enabled,
even for builds when the API keys are not configured.

Bug: 829220
Change-Id: I752bf7e9e03da0ddd33841e42ec1c550fcaf91c7
Reviewed-on: https://chromium-review.googlesource.com/1044210
Commit-Queue: Mihai Sardarescu <msarda@chromium.org>
Reviewed-by: Jesse Doherty <jwd@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556057}
[modify] https://crrev.com/de95b29a55c944b2540c43353de3201d7cb7de0f/chrome/browser/signin/account_consistency_mode_manager.cc
[modify] https://crrev.com/de95b29a55c944b2540c43353de3201d7cb7de0f/chrome/browser/signin/account_consistency_mode_manager.h
[modify] https://crrev.com/de95b29a55c944b2540c43353de3201d7cb7de0f/chrome/test/base/chrome_test_suite.cc
[modify] https://crrev.com/de95b29a55c944b2540c43353de3201d7cb7de0f/testing/variations/fieldtrial_testing_config.json

[Empty comment from Monorail migration]

This issue was migrated from crbug.com/chromium/829220?no_tracker_redirect=1

[Auto-CCs applied]
[Monorail components added to Component Tags custom field.]