Closed
Bug 1287607
Opened 8 years ago
Closed 8 years ago
Rules and Box Model inspector don't work with Protocol error (unknownError) in about:home
Categories
(DevTools :: Inspector, defect, P1)
DevTools
Inspector
Tracking
(firefox47 unaffected, firefox48 unaffected, firefox49 verified, firefox50 verified)
VERIFIED
FIXED
Firefox 50
Tracking | Status | |
---|---|---|
firefox47 | --- | unaffected |
firefox48 | --- | unaffected |
firefox49 | --- | verified |
firefox50 | --- | verified |
People
(Reporter: magicp.jp, Assigned: timhuang)
References
()
Details
(Keywords: regression)
Attachments
(2 files)
115.81 KB,
image/png
|
Details | |
1.36 KB,
patch
|
gl
:
review+
Sylvestre
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20160718081125 Steps to reproduce: 1. Start latest Nightly (e.g. Build: 20160718081125) 2. Open DevTools > Inspector > Rules 3. Open Box Model Actual results: Rules and Box Model inspector don't work with Protocol error (unknownError) Please find attached image. Protocol error (unknownError): Failed to open input source 'chrome://browser/content/abouthome/aboutHome.css'utils.js:157 Protocol error (unknownError): Failed to open input source 'chrome://browser/content/abouthome/aboutHome.css'utils.js:157 Protocol error (unknownError): Failed to open input source 'chrome://browser/content/abouthome/aboutHome.css'rules.js:878 Protocol error (unknownError): Failed to open input source 'chrome://browser/content/abouthome/aboutHome.css'Promise-backend.js:940 Expected results: Rules and Box Model works well.
Has STR: --- → yes
status-firefox50:
--- → affected
Component: Untriaged → Developer Tools: Inspector
OS: Unspecified → All
Hardware: Unspecified → All
URL: about:home
Summary: Rules and Box Model inspector don't work with Protocol error (unknownError) → Rules and Box Model inspector don't work with Protocol error (unknownError) in about:home
Also Style editor doesn't work Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=711963e8daa312ae06409f8ab5c06612cb0b8f7b&tochange=1d657d984bed365b1c2bdc499532cf34c60b1edd
Has Regression Range: --- → yes
Updated•8 years ago
|
Comment 2•8 years ago
|
||
Hello, is there a specific bug this regression is related to?
Flags: needinfo?(magicp.jp)
(In reply to Marco Mucci [:MarcoM] from comment #2) > Hello, is there a specific bug this regression is related to? Hi, my guess is Bug 1282660.
Flags: needinfo?(magicp.jp)
Updated•8 years ago
|
Priority: -- → P1
Carrying over ni? from bug 1287802 so we get a reply here.
Flags: needinfo?(tihuang)
Assignee | ||
Comment 6•8 years ago
|
||
For Bug 1282660, I had made changes that the stylesheets editor uses the content principal to load CSS files, but leaves the 'resource://' URL still using the system principal for loading since this load requires the system principal. Here, it looks like some 'chrome://' URL will be loaded by the stylesheets editor when the page is 'about:home'. So I think this could be fixed by making the 'chrome://' follows the same way as the 'resource://' URL.
Assignee: nobody → tihuang
Flags: needinfo?(tihuang)
Assignee | ||
Comment 7•8 years ago
|
||
Attachment #8772642 -
Flags: review?(gl)
Comment 8•8 years ago
|
||
Comment on attachment 8772642 [details] [diff] [review] Making the stylesheets editor using the system principal to load CSS files from 'chrome://' URL. Review of attachment 8772642 [details] [diff] [review]: ----------------------------------------------------------------- The original idea was to try treat these 'resource:' and 'chrome:' protocol differently. I am still hoping we can still find a better solution to this. Do you also think there are any additional protocols that we might've missed and needs to be specially handled? For example, I tried 'file:' which seems to be fine.
Attachment #8772642 -
Flags: review?(gl) → review+
Comment 9•8 years ago
|
||
(In reply to Tim Huang[:timhuang] from comment #6) > For Bug 1282660, I had made changes that the stylesheets editor uses the > content principal to load CSS files, but leaves the 'resource://' URL still > using the system principal for loading since this load requires the system > principal. > > Here, it looks like some 'chrome://' URL will be loaded by the stylesheets > editor when the page is 'about:home'. So I think this could be fixed by > making the 'chrome://' follows the same way as the 'resource://' URL. That was my initial assumption as well, but after digging a bit more, I don't know why some chrome:// URLs fail and some others don't. If you take about:tabcrashed and about:welcomeback, they both include "chrome://global/skin/in-content/info-pages.css". However tabcrashed has an empty rule, logging an error while fetching info-pages.css ; and welcomeback does not, you can even inspect rules defined in info-pages.css. After digging some more, it looks like this only affects "about:" pages that do not have chrome privileges (see URI_SAFE_FOR_UNTRUSTED_CONTENT in http://searchfox.org/mozilla-central/source/browser/components/about/AboutRedirector.cpp) I don't know how this can impact the solution here, but it makes sense: you cannot use the content principal to load chrome urls on pages that don't have chrome privileges.
Assignee | ||
Comment 11•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=acecbf5c3e72
Assignee | ||
Comment 12•8 years ago
|
||
(In reply to Gabriel Luong [:gl] (ΦωΦ) from comment #8) > Comment on attachment 8772642 [details] [diff] [review] > Making the stylesheets editor using the system principal to load CSS files > from 'chrome://' URL. > > Review of attachment 8772642 [details] [diff] [review]: > ----------------------------------------------------------------- > > The original idea was to try treat these 'resource:' and 'chrome:' protocol > differently. I am still hoping we can still find a better solution to this. > Do you also think there are any additional protocols that we might've missed > and needs to be specially handled? For example, I tried 'file:' which seems > to be fine. I don't know there are protocols that require the system principal to load other than 'resource:' and 'chrome:'. I am not really familiar with the 'file' protocol, but I think it should use the system principal to load because it involves local files, and I assume that the principal of the content page of the 'file:' protocol should be the system principal as well since other resources here should be located at local files. So we don't have to do anything on 'file:' protocol. And I had tested 'file:' protocols, it looks fine.
Assignee | ||
Updated•8 years ago
|
Status: NEW → ASSIGNED
Comment 14•8 years ago
|
||
Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/fx-team/rev/867a287c1fe1 Making the stylesheets editor using the system principal to load CSS files from 'chrome://' URL. r=gl
Keywords: checkin-needed
Comment 15•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/867a287c1fe1
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 50
Updated•8 years ago
|
status-firefox47:
--- → unaffected
status-firefox48:
--- → unaffected
status-firefox49:
--- → unaffected
Comment 16•8 years ago
|
||
Comment on attachment 8772642 [details] [diff] [review] Making the stylesheets editor using the system principal to load CSS files from 'chrome://' URL. Approval Request Comment [Feature/regressing bug #]: 1282660. This should be taken at the same time as Bug 1282660. We need to check the chrome protocol in addition to the resource protocol. [User impact if declined]: Unknown Error in DevTools > Inspector > Rules > Open Box Model on about:home [Describe test coverage new/current, TreeHerder]: Test in bug 1282660 [Risks and why]: Few line change that just builds on top of 1282660 to add a the chrome protocol. [String/UUID change made/needed]:None
Attachment #8772642 -
Flags: approval-mozilla-aurora?
Comment 17•8 years ago
|
||
Comment on attachment 8772642 [details] [diff] [review] Making the stylesheets editor using the system principal to load CSS files from 'chrome://' URL. Needed for the Test Pilot container/identity feature, taking it.
Attachment #8772642 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 18•8 years ago
|
||
As we are uplifting patches, this bug is going to affect 49 too.
Updated•8 years ago
|
Flags: qe-verify+
Comment 19•8 years ago
|
||
Reproduced the original issue using the STR from comment#0 using the following build: * build used: https://archive.mozilla.org/pub/firefox/nightly/2016/07/2016-07-18-08-11-25-mozilla-central/ ** fx50.0a1, buildId: 20160718081125, changeset: cde56ead650f * Win 10 x64 VM - Reproduced * OSX 10.11.6 x64 - Reproduced Protocol error (unknownError): Failed to open input source 'chrome://browser/content/abouthome/aboutHome.css'utils.js:157 Protocol error (unknownError): Failed to open input source 'chrome://browser/content/abouthome/aboutHome.css'rules.js:878 Protocol error (unknownError): Failed to open input source 'chrome://browser/content/abouthome/aboutHome.css'Promise-backend.js:940 Went through verification using the following build: * https://archive.mozilla.org/pub/firefox/nightly/2016/07/2016-07-27-03-02-30-mozilla-central/ * Win 10 x64 VM - Passed * OSX 10.11.6 x64 - Passed Test Cases Used: * went through the original STR from comment #0 () * went through Rules, Computed, Animations and Fonts under "Dev Tools -> Inspector" under about:home & about:newtab
Comment 20•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/15a01def6b14
Comment 21•8 years ago
|
||
Went through verification using the following buid: * fx49.0a2 buildId: 20160728110524, changeset: fbf0cb3a7651 Test Cases Used: * went through the original STR from comment#0 without any issues * went through the test cases listed under comment#19 without any issues
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•