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

commit 7db970e7b8673a26b5c09510f0badf4c690a3ccc
Author: Mythri Alle <mythria@chromium.org>
Date: Mon Sep 10 10:13:18 2018

Check if GeneratedCodeCacheContext is not null when using it

For Incognito mode (and other cases where code caches are disabled)
we do not create the GeneratedCodeCacheContext or the GeneratedCodeCache.
It is required to verify they are non-null before using them.

Bug:  chromium:881792 , chromium:881881
Change-Id: I9cf47ed45e88c2e4df1f4d0a499149893332c98a
Reviewed-on: https://chromium-review.googlesource.com/1215682
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#589873}
[modify] https://crrev.com/7db970e7b8673a26b5c09510f0badf4c690a3ccc/content/browser/renderer_host/render_message_filter.cc

@Mythri Alle: As the fix seems to be landed in comment#2, could you please let us know if this can be marked as "Fixed", only if no other fixes are in cue.

Thanks!

Closing the bug as a part of UI mass triage. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue.

oops. Sorry that I missed this somehow. The fix in comment 2 has nothing to do with this bug. It's just the wrong bug id. I am really sorry about this. I somehow didn't realize this earlier. So my is totally unrelated to this. That was a fix for 881881.

**UI mass Triage**

As per c#0, updating bug accordingly.

We were unable to find repro steps for this bug. If you have more data to
reproduce this bug or have clear repro steps, please reopen or file a new issue.

Thanks!

Here are updated repro steps:

1. Go to https://chromium-test1.appspot.com/testing/psl-matching/login
2. Login with "user"/"pass"
3. When asked to save password, do so.
4. In chrome://settings/passwords, verify that the password stored for "user" is "pass"
5. Logout
6. Login with ""/"accesskey" (empty user name - this simulates a page on the same domain that requires only a generic access key)
7. When asked to save/update password, note that the username is prefilled with "user". We do not want that! We want to save another entry with an empty username.
8. So we do just that: delete "user" from the "Update password" dialog. Note that the "Update password" buttons becomes a "Save" button as soon as we updated the username. The "Save" button remains a "Save" button even if the user name is fully deleted, indicating that we will not be updating user's password.
9. Click "Save"

Expected:
In chrome://settings/passwords, the password stored for "user" is "pass", and that "accesskey" is stored without a username.

Actual:
In chrome://settings/passwords, the password stored for "user" is "accesskey". This is a bug.

Refiled as Issue 908303