Closed Bug 1249934 Opened 4 years ago Closed 4 years ago

[e10s] "Unsafe CPOW usage forbidden" trying to use "cookie list"

Categories

(DevTools Graveyard :: Graphic Commandline and Toolbar, defect, P2)

47 Branch
defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 48

People

(Reporter: fyrenmoo, Assigned: jryans)

References

(Blocks 1 open bug)

Details

(Whiteboard: [btpp-fix-later])

Attachments

(2 files)

Using the latest 64-bit nightly (20160220030407), even in a fresh profile, I'm unable to use any of the "cookie" commands in the commandline toolbar.  Using any of them results in a popup/tooltip reporting "unsafe CPOW usage forbidden" with no other apparent effect.  I've attached the stack reported in the browser console.

After disabling e10s, the cookie commands work as expected.
OS: Windows 7 → Unspecified
Hardware: x86_64 → Unspecified
[Tracking Requested - why for this release]:

Seems like it was known as of bug 1142292 that we were using CPOWs.  However, it's now the case after bug 1233497 that these aren't allowed from browser code.

One solution would be to actually run this on the server as mentioned in bug 1221488.
Status: UNCONFIRMED → NEW
Depends on: 1221488
Ever confirmed: true
Priority: -- → P2
Whiteboard: [btpp-fix-later]
Blocks: dte10s
tracking-e10s: --- → +
[Tracking Requested - why for this release]: Tracked for 47 and nom'ing for tracking in 46.
Tracking for 46 as well since we are doing some e10s staged rollouts in 46.
Looking back at this, for e10s regressions that aren't blocking beta or release rollout (e10s:m8 or m9) I don't want to track for 46.  Still would be nice to fix it and uplift to the current dev edition though.
Duplicate of this bug: 1257483
I'm getting this same exact problem on FirefoxDeveloperEdition 47.0a2 (2016-03-23) on OS X 10.11.4. I've been getting it for at least a few days now. I just turned off e10s to test, and I can now use `cookie list` again. No more "unsafe CPOW usage forbidden" message. I just turned e10s back on, and I still see the message.
This should only occur in 47 and later due to bug 1233497.
We can fix this without server-parent (bug 1249934).  We only need access to the URL.
Assignee: nobody → jryans
Status: NEW → ASSIGNED
No longer depends on: 1221488
Attachment #8733933 - Flags: review?(jwalker) → review+
https://hg.mozilla.org/mozilla-central/rev/d2518d6b0592
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Comment on attachment 8733933 [details]
MozReview Request: Bug 1249934 - Avoid CPOWs in GCLI cookie commands. r=jwalker

Approval Request Comment
[Feature/regressing bug #]: Issue triggered by bug 1233497 which throws when browser code uses CPOWs.
[User impact if declined]: If declined, the some Developer Toolbar commands will be broken.
[Describe test coverage new/current, TreeHerder]: Manual testing, landed on m-c
[Risks and why]: Low risk, only affects Developer Toolbar commands in DevTools
[String/UUID change made/needed]: None
Attachment #8733933 - Flags: approval-mozilla-aurora?
Comment on attachment 8733933 [details]
MozReview Request: Bug 1249934 - Avoid CPOWs in GCLI cookie commands. r=jwalker

Recent regression and locally tested, Aurora47+
Attachment #8733933 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Happens again in Firefox56-b2, I came here through a google search of the error...
Same problem w/ Firefox 55 release channel.
+ on top of command line erroring out, Dev Tools > Storage cookie editor allows adding cookies, but any edits to the added one get discarded. Looks like I'm stuck now.
With the 55.0.2 release, I too see the "Error: unsafe CPOW usage forbidden" error when attempting to use the "cookie list" command via Tools > Developer Toolbar.
+1. I'm seeing this on 55.0.3. This was working the last time I tried which was sometime this year, so probably between 47 and 55. So it must have gotten broken again sometime after 47.
Happens for me on Firefox Developer Edition 58.0b1.

13:08:39.760 Error: unsafe CPOW usage forbidden
Stack trace:
exec@resource://devtools/shared/base-loader.js -> resource://devtools/shared/gcli/commands/cookie.js:97:11
Requisition.prototype.exec/<@resource://devtools/shared/base-loader.js -> resource://devtools/shared/gcli/source/lib/gcli/cli.js:2085:16
asyncFunction@resource://devtools/shared/base-loader.js -> resource://devtools/shared/task.js:235:18
spawn@resource://devtools/shared/base-loader.js -> resource://devtools/shared/task.js:160:12
exports.exec@resource://devtools/shared/base-loader.js -> resource://devtools/shared/gcli/source/lib/gcli/util/host.js:63:10
Requisition.prototype.exec@resource://devtools/shared/base-loader.js -> resource://devtools/shared/gcli/source/lib/gcli/cli.js:2084:14
Inputter.prototype._handleReturn@resource://devtools/shared/base-loader.js -> resource://devtools/shared/gcli/source/lib/gcli/mozui/inputter.js:569:12
Inputter.prototype.handleKeyUp@resource://devtools/shared/base-loader.js -> resource://devtools/shared/gcli/source/lib/gcli/mozui/inputter.js:465:12
Inputter.prototype.onKeyUp@resource://devtools/shared/base-loader.js -> resource://devtools/shared/gcli/source/lib/gcli/mozui/inputter.js:437:3
 1 cli.js:2056
Why is this bug marked as fixed if it still happens on latest Firefox?
Still happens in the latest Firefox Developer Version 59.0b7.
This bug needs to be reopened, or else a new one filed.

It may well have been fixed two years ago, but if it was, it clearly regressed at least seven months ago.
(In reply to Santiago Gala from comment #17)
(In reply to Leho Kraav (:macmaN @lkraav) from comment #18)
(In reply to Forest Hoffman from comment #20)
(In reply to nick from comment #21)
(In reply to mbudde from comment #22)
(In reply to baptx from comment #23)
(In reply to hyiltiz from comment #24)
(In reply to Chris Morgan from comment #25)

In case of a regression,
1. Search to see if the issue has already been reported [a].
2. If there's seemingly no report, file a new one.
3. Try to find the exact regression range using mozregression(-gui) [b].
4. If you found the exact bug that caused the regression, mark yours as blocking that one, add the patch author to the CC list, and set the needinfo flag ("Need more information from" below the comment box). Also include the pushlog link (https://hg.mozilla.org/…) in your bug report.
5. If you can't look for the regression range, try to be as specific as possible about the last time the feature worked.

[a] Bug 1376726
[b] https://mozilla.github.io/mozregression/quickstart.html
Product: Firefox → DevTools
This is broken (still/again/whatever) in 61.0.2

No, I don't know when it broke and I don't know when it was last working.

1. Search to see if the issue has already been reported [a].
That's how I get here. Yes, this has been reported.  See this page.

2. If there's seemingly no report, file a new one.
See 1.

3. Try to find the exact regression range using mozregression(-gui) [b].
I don't know when it was last working so I can't do this.

4. If you found the exact bug that caused the regression, mark yours as blocking that one, add the patch author to the CC list, and set the needinfo flag ("Need more information from" below the comment box). Also include the pushlog link (https://hg.mozilla.org/…) in your bug report.
I'm not filing a new bug report because you said in number 2 to file a new one if there's "seemingly no report", but there is a report (with users telling you it's still broken, yet you're ignoring them).  Thus, there's no way for me to mark "mine" as blocking "that one", nor can I include a "pushlog" link because I don't know when this rebroke, nor do I know if it was ever truly fixed.  If I reported a new bug for this issue, it would be marked as dupe and closed.

5. If you can't look for the regression range, try to be as specific as possible about the last time the feature worked.
The last time I personally used it was probably over 6 months ago.

The bottom line is that I, as the user of the browser, should never be blocked from seeing or modifying cookies.  The cookies are my data.  The fact that I get an error when attempting to use "cookie list" is a bug.  The fact that it happens in the latest build means the bug is not resolved in the latest build.
tracking-e10s: + → ---
Flags: needinfo?(gingerbread_man)
(In reply to Anon from comment #27)
First of all, it was extremely poor form to botch the tracking flags as you've done. I can't even restore them as they were.

Secondly, I explicitly mentioned the issue that's bothering you has already been reported as bug 1376726.

Thirdly, the graphic command line has been removed altogether in Firefox 62. That's bound to have resolved issue. You could've verified this by launching the latest Nightly in a brand new profile.

Lastly, for future reference, as I tried to explain at comment 26, this report is resolved as Fixed. In such a case, a re-emergence of the same issue in a later version is a regression. That requires a new bug report, if one doesn't already exist. When you know there was no bug approximately 6 months prior, in mozregression(-gui), set 7 months ago as the date of the last known good build.

Please read the bug writing guidelines and Bugzilla etiquette pages before participating in this site again.
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Flags: needinfo?(gingerbread_man)
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.