Firefox 80 should pick up NSPR 4.27
Categories
(Firefox Build System :: General, enhancement)
Tracking
(firefox80 fixed)
| Tracking | Status | |
|---|---|---|
| firefox80 | --- | fixed |
People
(Reporter: KaiE, Assigned: KaiE)
References
Details
Attachments
(4 files)
|
(deleted),
text/x-phabricator-request
|
Details | |
|
Bug 1652330 - NSPR 4.27 dev snapshot 2 to pick up a fix for macOS 11. r=kjacobs UPGRADE_NSPR_RELEASE
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
text/x-phabricator-request
|
Details | |
|
(deleted),
text/x-phabricator-request
|
Details |
Firefox 80 should pick up NSPR 4.27
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 1•4 years ago
|
||
UPGRADE_NSPR_RELEASE
|
|
Assignee | |
Updated•4 years ago
|
|
||
Comment 3•4 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 4•4 years ago
|
||
|
||
Comment 5•4 years ago
|
||
We'll also need the PR_Access fix uplifted to ESR 68, to address bug 1649764.
|
|
Assignee | |
Comment 6•4 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #5)
We'll also need the PR_Access fix uplifted to ESR 68, to address bug 1649764.
ESR 68 ? Or ESR 78 ? Or both?
Those branches use older NSPR releases. To uplift, I'll have to create matching NSPR branch releases.
It seems :glandium is worried that the fix from bug 1652956 might regress an original fix from bug 480730.
But I have trouble to understand which regression that would be.
I'd like to wait for glandium's response, prior to creating the NSPR branch releases.
|
|
||
Comment 7•4 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #6)
(In reply to Markus Stange [:mstange] from comment #5)
We'll also need the PR_Access fix uplifted to ESR 68, to address bug 1649764.
ESR 68 ? Or ESR 78 ? Or both?
Probably both; definitely 78. (I'm not sure how long we support 68.)
Bug 1649764 was filed about 68 and also mentions the Tor browser.
The current status is that 68 cannot render web content on macOS Big Sur because 68 requires OpenGL for that.
78 can render web content on macOS Big Sur (because of a different fix that allows using BasicCompositor without OpenGL), but it does not have hardware acceleration or WebGL on macOS Big Sur.
(In reply to Kai Engert (:KaiE:) from comment #6)
I'd like to wait for glandium's response, prior to creating the NSPR branch releases.
That sounds good to me.
|
||
Updated•4 years ago
|
|
||
Comment 9•4 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 10•4 years ago
|
||
So there was indeed a regression found, in NSS. In the meantime we understand what's happening.
I'm not yet sure what we should do on old branches.
Let's wait for the discussion that i started in bug 1648836 comment 13.
|
|
Assignee | |
Comment 11•4 years ago
|
||
To clarify:
Creating .x updates of the old NSPR releases is possible.
However, everyone using macOS with those old NSPR versions and also using NSS would potentially run into a regression (incorrect library of root CA certificates being loaded).
We'd have to require that all NSPR users on macOS also upgrade to a fixed NSS.
It would require that in addition to old NSPR .x updates, corresponding NSS .x updates would have to be released, too.
If bug 1648836 gives us a simple answer to my question, then we could avoid the change of behavior in old NSPR, by limiting the change to known macOS system libraries.
|
|
Assignee | |
Comment 12•4 years ago
|
||
|
|
Assignee | |
Comment 13•4 years ago
|
||
|
|
||
Updated•4 years ago
|
|
||
Comment 14•4 years ago
|
||
|
||
Comment 15•4 years ago
|
||
| bugherder | ||
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 16•4 years ago
|
||
|
|
||
Updated•4 years ago
|
|
|
||
Comment 17•4 years ago
|
||
|
||
Comment 18•4 years ago
|
||
| bugherder | ||
Description
•