Approval Request Comment [Feature/Bug causing the regression]: Race condition when third-party products start threads in our main process during Firefox startup. [User impact if declined]: For people who were crashing in bug 1850969: occasional failure to honor the dynamic DLL blocklist (when they would have crashed). For all people with third-party products starting threads early in our process: potential occasional unknown consequences of the race condition. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes, we verified that the fix does not introduce hangs for the Nightly population - as far as we know. [Needs manual test from QE? If yes, steps to reproduce]: Yes - checking that Firefox starts during usual recurrent antivirus testing. [List of other uplifts needed for the feature/fix]: The other patch from bug 1850969 (D187913) which has already been lifted to 118 beta. [Is the change risky?]: Medium [Why is the change risky/not risky?]: A bit risky because we are already in 118 RC and the Nightly population is not the best population to test interaction with third-party products (e.g. only five crashes from Nightly users over the last 6 months for the signatures in bug 1850969). Not so risky because the patch is simple and the potential unknown consequences of the race condition feel more risky than the patch. [String changes made/needed]: ESR Approval Request Comment [Feature/Bug causing the regression]: Race condition when third-party products start threads in our main process during Firefox startup. [User impact if declined]: For people who were crashing in bug 1850969: occasional failure to honor the dynamic DLL blocklist (when they would have crashed). For all people with third-party products starting threads early in our process: potential occasional unknown consequences of the race condition. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes, we verified that the fix does not introduce hangs for the Nightly population - as far as we know. [Needs manual test from QE? If yes, steps to reproduce]: Yes - checking that Firefox starts during usual recurrent antivirus testing. [List of other uplifts needed for the feature/fix]: The other patch from bug 1850969 (D187913) which has already been lifted to 115 ESR. [Is the change risky?]: Medium [Why is the change risky/not risky?]: A bit risky because we are shipping soon and the Nightly population is not the best population to test interaction with third-party products (e.g. only five crashes from Nightly users over the last 6 months for the signatures in bug 1850969). Not so risky because the patch is simple and the potential unknown consequences of the race condition feel more risky than the patch. [String changes made/needed]: See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Bug 1852841 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Approval Request Comment [Feature/Bug causing the regression]: Race condition when third-party products start threads in our main process during Firefox startup. [User impact if declined]: For people who were crashing in bug 1850969: occasional failure to honor the dynamic DLL blocklist (when they would have crashed). For all people with third-party products starting threads early in our process: potential occasional unknown consequences of the race condition. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes, we verified that the fix does not introduce hangs for the Nightly population - as far as we know. [Needs manual test from QE? If yes, steps to reproduce]: Yes - check that Firefox starts with the usual antivirus products we test. [List of other uplifts needed for the feature/fix]: The other patch from bug 1850969 (D187913) which has already been lifted to 118 beta. [Is the change risky?]: Medium [Why is the change risky/not risky?]: A bit risky because we are already in 118 RC and the Nightly population is not the best population to test interaction with third-party products (e.g. only five crashes from Nightly users over the last 6 months for the signatures in bug 1850969). Not so risky because the patch is simple and the potential unknown consequences of the race condition feel more risky than the patch. [String changes made/needed]: ESR Approval Request Comment [Feature/Bug causing the regression]: Race condition when third-party products start threads in our main process during Firefox startup. [User impact if declined]: For people who were crashing in bug 1850969: occasional failure to honor the dynamic DLL blocklist (when they would have crashed). For all people with third-party products starting threads early in our process: potential occasional unknown consequences of the race condition. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes, we verified that the fix does not introduce hangs for the Nightly population - as far as we know. [Needs manual test from QE? If yes, steps to reproduce]: Yes - check that Firefox starts with the usual antivirus products we test. [List of other uplifts needed for the feature/fix]: The other patch from bug 1850969 (D187913) which has already been lifted to 115 ESR. [Is the change risky?]: Medium [Why is the change risky/not risky?]: A bit risky because we are shipping soon and the Nightly population is not the best population to test interaction with third-party products (e.g. only five crashes from Nightly users over the last 6 months for the signatures in bug 1850969). Not so risky because the patch is simple and the potential unknown consequences of the race condition feel more risky than the patch. [String changes made/needed]: See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Approval Request Comment [Feature/Bug causing the regression]: Race condition when third-party products start threads in our main process during Firefox startup. [User impact if declined]: For people who were crashing in bug 1850969: occasional failure to honor the dynamic DLL blocklist (when they would have crashed). For all people with third-party products starting threads early in our process: potential occasional unknown consequences of the race condition. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes, we verified that the fix does not introduce hangs for the Nightly population - as far as we know. [Needs manual test from QE? If yes, steps to reproduce]: Yes - check that Firefox starts with the usual antivirus products we test (launch Firefox at least twice for each product). [List of other uplifts needed for the feature/fix]: The other patch from bug 1850969 (D187913) which has already been lifted to 118 beta. [Is the change risky?]: Medium [Why is the change risky/not risky?]: A bit risky because we are already in 118 RC and the Nightly population is not the best population to test interaction with third-party products (e.g. only five crashes from Nightly users over the last 6 months for the signatures in bug 1850969). Not so risky because the patch is simple and the potential unknown consequences of the race condition feel more risky than the patch. [String changes made/needed]: ESR Approval Request Comment [Feature/Bug causing the regression]: Race condition when third-party products start threads in our main process during Firefox startup. [User impact if declined]: For people who were crashing in bug 1850969: occasional failure to honor the dynamic DLL blocklist (when they would have crashed). For all people with third-party products starting threads early in our process: potential occasional unknown consequences of the race condition. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes, we verified that the fix does not introduce hangs for the Nightly population - as far as we know. [Needs manual test from QE? If yes, steps to reproduce]: Yes - check that Firefox starts with the usual antivirus products we test (launch Firefox at least twice for each product). [List of other uplifts needed for the feature/fix]: The other patch from bug 1850969 (D187913) which has already been lifted to 115 ESR. [Is the change risky?]: Medium [Why is the change risky/not risky?]: A bit risky because we are shipping soon and the Nightly population is not the best population to test interaction with third-party products (e.g. only five crashes from Nightly users over the last 6 months for the signatures in bug 1850969). Not so risky because the patch is simple and the potential unknown consequences of the race condition feel more risky than the patch. [String changes made/needed]: See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Approval Request Comment [Feature/Bug causing the regression]: Race condition when third-party products start threads in our main process during Firefox startup. [User impact if declined]: For people who were crashing in bug 1850969: occasional failure to honor the dynamic DLL blocklist (when they would have crashed). For all people with third-party products starting threads early in our process: potential occasional unknown consequences of the race condition. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes, we verified that the fix does not introduce hangs for the Nightly population - as far as we know. [Needs manual test from QE? If yes, steps to reproduce]: Yes - check that Firefox starts on Windows 10 with the usual antivirus products we test (launch Firefox at least twice for each product). [List of other uplifts needed for the feature/fix]: The other patch from bug 1850969 (D187913) which has already been lifted to 118 beta. [Is the change risky?]: Medium [Why is the change risky/not risky?]: A bit risky because we are already in 118 RC and the Nightly population is not the best population to test interaction with third-party products (e.g. only five crashes from Nightly users over the last 6 months for the signatures in bug 1850969). Not so risky because the patch is simple and the potential unknown consequences of the race condition feel more risky than the patch. [String changes made/needed]: ESR Approval Request Comment [Feature/Bug causing the regression]: Race condition when third-party products start threads in our main process during Firefox startup. [User impact if declined]: For people who were crashing in bug 1850969: occasional failure to honor the dynamic DLL blocklist (when they would have crashed). For all people with third-party products starting threads early in our process: potential occasional unknown consequences of the race condition. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes, we verified that the fix does not introduce hangs for the Nightly population - as far as we know. [Needs manual test from QE? If yes, steps to reproduce]: Yes - check that Firefox starts on Windows 10 with the usual antivirus products we test (launch Firefox at least twice for each product). [List of other uplifts needed for the feature/fix]: The other patch from bug 1850969 (D187913) which has already been lifted to 115 ESR. [Is the change risky?]: Medium [Why is the change risky/not risky?]: A bit risky because we are shipping soon and the Nightly population is not the best population to test interaction with third-party products (e.g. only five crashes from Nightly users over the last 6 months for the signatures in bug 1850969). Not so risky because the patch is simple and the potential unknown consequences of the race condition feel more risky than the patch. [String changes made/needed]: See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.