Allow XUL panel in content frames to leave the frame area

RESOLVED FIXED in Firefox 68

Status

()

defect
P3
normal
RESOLVED FIXED
5 months ago
4 months ago

People

(Reporter: jdescottes, Assigned: jdescottes)

Tracking

unspecified
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(2 attachments)

Spawned from Bug 1539979, comment from Neil on the phabricator review https://phabricator.services.mozilla.com/D25306#762951

In D25306#759443, @bgrins wrote:

Is there some special cased code to handle somehow constraining panels in a
content browser? And if so, is there a way to bypass that for this use case?

Yes, popups in content frames are constrained to the area of their frame. You
could modify something that sets nsMenuPopupFrame::mInContentShell to disable
this behaviour, but it should be chrome-only.

We want to run DevTools in a frame with type="content", but we need XUL panels to be able to leave the frame area.

(more a feedback request than review request at this stage)

Adding a new attribute to the panel was the easiest way I could find to make this work without too much plumbing
However I don't know how to check that the attribute comes from a chrome privileged script. I tried using PresContext()->IsChrome() but this is also false in our situation.

Would you prefer another approach? Otherwise what kind of test would you write for this kind of feature?

Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e8c98e4ec66e
Support incontentshell attribute for XUL panel;r=NeilDeakin
https://hg.mozilla.org/integration/autoland/rev/d2db177d667f
Set incontentshell=false for devtools popups and panels r=bgrins
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.