100% CPU load on LinkedIn login page when Primary Password is set and credentials are saved
Categories
(Core :: DOM: Web Authentication, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | fixed |
firefox134 | --- | wontfix |
firefox135 | --- | fixed |
firefox136 | --- | fixed |
People
(Reporter: whimboo, Assigned: jschanck)
References
(Blocks 1 open bug, Regression, )
Details
(5 keywords)
Seen with Firefox 134 – macOS 14.7.1
I closed the current window and reopened it via the history menu. After it was opened again I saw a 100% CPU load of a single content process which includes the tab with the LinkedIn login page. That high load was visible as well when the tab is in the background.
Here a recorded Gecko profile: https://share.firefox.dev/3C0IIib
After logging in to the site the high CPU load was gone.
Comment 1•2 months ago
|
||
Did you have the webdev toolbar opened somewhere? (I see a lot of time spent in mozilla::dom::PromiseDebugging::AddConsumedRejection).
Reporter | ||
Comment 2•2 months ago
|
||
I'm fairly sure that whether the integrated nor the browser toolbox was open at that time. Also by reopening a formerly closed window, all integrated dev tools frames are no longer open.
![]() |
||
Comment 3•2 months ago
|
||
I can reproduce on Nightly135.0a1 Windows11.
Prerequisite: Saved logins and set primary password. And make sure that not logged in to the website.
STR:
- Start Firefox with the profile prepared above
- Open https://www.linkedin.com/login/ja
- Enter primary password
AR:
That page is not responsive to mouse or keyboard.
Profiler: https://share.firefox.dev/4gIUPQb
Regression window:
mozilla-central:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=81869d55a8d7b3d1d573810ab4e99f63cbe11a8a&tochange=bf4c1083cec10076ccbf07f2cfc3e18b04d0bf72
Reporter | ||
Comment 4•2 months ago
|
||
Alice thanks for checking! I assume you also didn't had the dev tools open given that mozilla::dom::PromiseDebugging::AddConsumedRejection
is visible in the profile as well.
Reporter | ||
Comment 5•2 months ago
|
||
(In reply to Alice0775 White from comment #3)
Maybe this is related to the WebAuthn changes landed within that range? Do you have a chance to nail down this range even further?
![]() |
||
Comment 6•2 months ago
|
||
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #4)
Alice thanks for checking! I assume you also didn't had the dev tools open given that
The dev tools are not open.
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #5)
(In reply to Alice0775 White from comment #3)
Maybe this is related to the WebAuthn changes landed within that range? Do you have a chance to nail down this range even further?
It is difficult. I haven't installed the development environment.
Reporter | ||
Comment 7•2 months ago
|
||
Ok, maybe John can give some feedback for now. I won't have the time to dig into it myself before next week.
Comment 8•1 month ago
|
||
The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.
Websites affected: Major
Resource impact: Severe
[x] Able to reproduce locally
Assignee | ||
Comment 9•1 month ago
|
||
Do we know if this happens when a primary password is not set?
From the profile, it looks like code on the page is repeatedly calling navigator.credentials.get. Looking at the javascript, that call to navigator.credentials.get is in this block:
for (; ; ) switch (e.prev = e.next) {
case 0:
return e.next = 2,
navigator.credentials.get(x(t)).then((function (e) {
return _(e)
})).catch((function (e) {
if ('AbortError' !== e) return Promise.resolve(h)
}));
case 2:
return e.abrupt('return', e.sent);
case 3:
case 'end':
return e.stop()
}
}
I'm not set up to reproduce this at the moment (I don't have a linkedin login), but if I was I would set a breakpoint in the if ('AbortError' !== e)
line and check if, perhaps, we're returning an AbortError.
Reporter | ||
Comment 10•1 month ago
|
||
Alice, would you have the chance to check the above? I sadly have issues to reproduce it on my local machine. Thanks!
![]() |
||
Comment 11•1 month ago
|
||
(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #10)
Alice, would you have the chance to check the above? I sadly have issues to reproduce it on my local machine. Thanks!
I was able to reproduce the problem with the latest Nightly136.0a1 if the primary password was set.
However, when the primary password was not set, the userid & password were prefilled correctly, the sign-in button was clickable, and it worked correctly without freezing.
Assignee | ||
Comment 12•1 month ago
|
||
Thanks! I think the issue here is that the primary password prompt causes the document to lose focus and that results in the conditionally mediated WebAuthn request being rejected with a NotAllowedError (See Bug 1930028).
The spec says:
When the Window object associated with the Document loses focus, [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) operations SHOULD be aborted.
So I think we should be returning AbortError in this case.
Reporter | ||
Comment 13•1 month ago
|
||
John, so this bug is a regression right? Can you please add the keyword and the reference to the bug which regressed it? Thanks.
![]() |
||
Updated•1 month ago
|
Reporter | ||
Updated•1 month ago
|
Reporter | ||
Comment 14•1 month ago
|
||
Steps for me are:
- Create a fresh profile
- Open the above website, enter some random data into the login field and store them in the password database
- Open the settings and enable the Primary Password
- Stay in settings and enable the option to reopen the set of tabs from the last session on startup
- Restart Firefox and wait some seconds (it usually takes 2-3s until the 100% CPU load is visible)
I also cannot build such an old changeset due to build system issues on MacOS M1. But only the patch on bug 1838932 actually changes code that includes Promises so I would say it is the regressor. John, if you think different please change it. ``
Updated•1 month ago
|
Assignee | ||
Updated•1 month ago
|
Reporter | ||
Comment 16•1 month ago
|
||
Bug 1930028 is not marked as a regression and probably isn't because it was a new feature that was added but not working correctly under a specific condition. But this bug is about a change in behavior and as well tracks the perf related work. I would suggest to not duplicate but mark it as fixed based on the landed work on bug 1930028.
I just tested and can indeed not see any further high CPU load on the LinkedIn website. Thanks!
Updated•29 days ago
|
Updated•29 days ago
|
Description
•