Note that enabling a FFOS-oriented API like mozbrowser has the effect of
turning it on for web content (with some set of permissions) rather than
"for chrome", since that's how things work in FFOS. So any work to use
mozbrowser on Desktop should take extreme care not to accidentally expose
it to
On Fri, Jan 8, 2016 at 12:13 PM, Bobby Holley wrote:
> Note that enabling a FFOS-oriented API like mozbrowser has the effect of
> turning it on for web content (with some set of permissions) rather than
> "for chrome", since that's how things work in FFOS. So any work to
What prevents you from using ? Is it because the parent
frame is (X)HTML?
I don't know what prevents browser-element from being enabled on desktop
though -- it's tests are running on desktop, and the actual feature is
hidden behind a permission so we won't expose it to the web content even if
we
I have filed bug 1238160 to investigate and hopefully enable
mozbrowser on desktop Firefox.
- Ryan
On Fri, Jan 8, 2016 at 3:23 PM, J. Ryan Stinnett wrote:
> On Fri, Jan 8, 2016 at 12:13 PM, Bobby Holley wrote:
>> Note that enabling a FFOS-oriented API
Regardless of technical feasibility, I believe we're discouraging new
uses of XUL in Firefox.
/a
On 1/8/16 04:55, Tim Guan-tin Chien wrote:
What prevents you from using ? Is it because the parent
frame is (X)HTML?
I don't know what prevents browser-element from being enabled on desktop
On Fri, Jan 8, 2016 at 4:55 AM, Tim Guan-tin Chien wrote:
> What prevents you from using ? Is it because the parent
> frame is (X)HTML?
Placing a regular, non-remote in the HTML page does
work. However, does not work in my specific
context according to the policy of
6 matches
Mail list logo