Bugzilla

(In reply to erosman from comment #14)
> I did try to bisect it by manually downloading and installing previous versions of Nightly as in comment #8. 
> 
> _mozregression does not run on my Win7 OS and that has been the case for many years. There are Python errors. Installing various versions of Python didn't help either._
> 
> Looking at _Developer Tools ➜ Style Editor_, it may !!? relate to CSS `@import` as I don't see the files loaded. I also use `@import` in the browserAction pop-ups. Although, the pop-ups that don't have `@import` also fail.
> 
> As mentioned in the first post, commenting out the `<link rel="stylesheet" href="popup.css">` will result in the pop-up showing (but looking bad). This point does not relate to the issues in bug 1735347.
> 
> Please note that there are specific setting in `about:config` that relate to Win7. There are a few OS-specific locked entries as I found out when discussing anther matter in #amo:mozilla.org which may explain why the issue in not happening for everyone.
> 
> N.B. As I type and as pop-ups fail and as extension option pages fail, I opened a new Private window and everything works fine in that private window.
> After a while, that private window will also start to experience the same failures and I would be forced to restart Firefox in order to access pop-up & options.
> 
> _PS. In case this has a bearing on the issue, all my extensions are under development and are loaded unpacked as it has been for many years._
> 
> **Update:**
> It has already been 10 days and it appears that the failures, when happen, only happen for the above mentioned unpacked add-ons. I have 2 other addons (uBlock Origin & uMatirx) and their pop-ups haven't failed yet. Considering that loading stylesheets seems to be a factor, could there have been some changes to the stylesheet loading process on Oct 9th-10th  that is affecting the loading from unpacked & out of Firefox own filesystem location?

The only one that I can think of right now is https://bugzilla.mozilla.org/show_bug.cgi?id=1706594, which got on mozilla-central on Oct 11:

- The stylesheets listed in an html document do trigger a speculative load, which was one of the kind of requests that were able to trigger that bug
- the fix explicitly cancel streams that are related to channels that were already canceled and so in theory it shouldn't be preventing the page in the popup from opening correctly
- but the bug was also more likely to happen for unpacked extensions (I couldn't find a way to reproduce it with packed ones)

and so there are 2 parts of your STR that seems to have some kind of connection with that fix.

It would be great if we could confirm if that is actually the case, would you mind to send me the about:support information and any specific setting in `about:config` that you already know that relates only to Window 7?

Being able to reproduce the issue locally would allow me to confirm if there is any actual connection between the issue you are experiencing and the fix we landed for Bug 1706594, and in either case (related or not to Bug 1706594) to dig more into it and get a better picture of what is really going on.

Alternatively (or in addition to that), I may try to revert that commit locally and push it to try, this way you may try on your system a build that includes everything that is already in Nightly besides that single change.

(In reply to erosman from comment #14)
> I did try to bisect it by manually downloading and installing previous versions of Nightly as in comment #8. 
> 
> _mozregression does not run on my Win7 OS and that has been the case for many years. There are Python errors. Installing various versions of Python didn't help either._
> 
> Looking at _Developer Tools ➜ Style Editor_, it may !!? relate to CSS `@import` as I don't see the files loaded. I also use `@import` in the browserAction pop-ups. Although, the pop-ups that don't have `@import` also fail.
> 
> As mentioned in the first post, commenting out the `<link rel="stylesheet" href="popup.css">` will result in the pop-up showing (but looking bad). This point does not relate to the issues in bug 1735347.
> 
> Please note that there are specific setting in `about:config` that relate to Win7. There are a few OS-specific locked entries as I found out when discussing anther matter in #amo:mozilla.org which may explain why the issue in not happening for everyone.
> 
> N.B. As I type and as pop-ups fail and as extension option pages fail, I opened a new Private window and everything works fine in that private window.
> After a while, that private window will also start to experience the same failures and I would be forced to restart Firefox in order to access pop-up & options.
> 
> _PS. In case this has a bearing on the issue, all my extensions are under development and are loaded unpacked as it has been for many years._
> 
> **Update:**
> It has already been 10 days and it appears that the failures, when happen, only happen for the above mentioned unpacked add-ons. I have 2 other addons (uBlock Origin & uMatirx) and their pop-ups haven't failed yet. Considering that loading stylesheets seems to be a factor, could there have been some changes to the stylesheet loading process on Oct 9th-10th  that is affecting the loading from unpacked & out of Firefox own filesystem location?

The only one that I can think of right now is https://bugzilla.mozilla.org/show_bug.cgi?id=1706594, which got on mozilla-central on Oct 11:

- The stylesheets listed in an html document do trigger a speculative load, which was one of the kind of requests that were able to trigger that bug
- the fix explicitly cancel streams that are related to channels that were already canceled and so in theory it shouldn't be preventing the page in the popup from opening correctly
- but the bug was also more likely to happen for unpacked extensions (I couldn't find a way to reproduce it with packed ones)

and so there are 2 parts of your STR that seems to have some kind of connection with that fix.

It would be great if we could confirm if that is actually the case, would you mind to send me the about:support information and any specific setting in `about:config` that you already know that relates only to Window 7?

Being able to reproduce the issue locally would allow me to confirm if there is any actual connection between the issue you are experiencing and the fix we landed for Bug 1706594, and in either case (related or not to Bug 1706594) to dig more into it and get a better picture of what is really going on.

Alternatively (or in addition to that), I create a backout commit locally and push it to try, this way you may try on your system a build that includes everything that is already in Nightly besides that single change, you can download the custom build from here:
- https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GUI--PtYSTyKRAH4PsL1cw/runs/0/artifacts/public/build/target.zip

Let me know if you are unable to reproduce the issue in this build but you are able to reproduce it on the last nightly build.