You need to enable the mozbrowser attribute by flipping
dom.mozBrowserFramesEnabled
And you need the browser permission.
layout/base/tests/test_remote_passpointerevents.html is a good example.
Kanru
Nicholas Nethercote n.netherc...@gmail.com writes:
Hi,
I want to create a child process
On 9/6/2013 2:32 AM, Nicholas Nethercote wrote:
In theory, this is as easy as iframe mozbrowser remote or browser
remote
html:iframe mozbrowser remote is what B2G uses. It requires the prefs
than Kan-Ru mentions.
xul:browser remote=true is what desktop uses. It does not require
special
On 2013-08-03 12:21:57 +, Paolo Amadini said:
The complete documentation of the module can be found here:
https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Downloads.jsm
Paulo: On behalf of the documentation team, I want to thank you for
documenting this! We always
Here is the CPOW test that creates a remote browser:
http://mxr.mozilla.org/mozilla-central/source/content/base/test/chrome/test_cpows.xul
On Fri, Sep 6, 2013 at 9:41 AM, Neil n...@parkwaycc.co.uk wrote:
Nicholas Nethercote wrote:
In theory, this is as easy as iframe mozbrowser remote or
On 06/09/13 16:17, Adam Roach wrote:
To the first point: the increase in complexity is fairly minimal for a
substantial gain in usability. Absent hard statistics, I suspect we will
disagree about how fringe this particular exception is. Suffice it to
say that I have personally encountered it
On 9/6/13 04:25, Henri Sivonen wrote:
We do surface such UI for https deployment errors
inspiring academic papers about how bad it is that users are exposed
to such UI.
Sure. It's a much trickier problem (and, in any case, the UI is
necessarily more intrusive than what I'm suggesting).
On 06/09/13 16:45, Robert Kaiser wrote:
Henri Sivonen schrieb:
Considering what Aryeh said earlier in this thread, do you have a
suggestion how to do that so that
[...]
Hmm, do we have to treat the whole document as a consistent charset?
Could we instead, if we don't know the charset, look
On 06/09/13 16:34, Gervase Markham wrote:
Data! Sounds like a plan.
Or we could ask our friends at Google or some other search engine to run
a version of our detector over their index and see how often it says
UTF-8 when our normal algorithm would say something else.
Gerv
This website has an
On 9/5/13 10:32 AM, Nicolas B. Pierron wrote:
On 09/05/2013 09:51 AM, Ehsan Akhgari wrote:
On 2013-09-03 9:39 PM, Aki Sasaki wrote:
On 9/3/13 8:25 AM, Ehsan Akhgari wrote:
2. How frequently are these branches updated?
The current job is running on a 5 minute cron job. We can, of course,
On 06/09/13 17:48, Marcos Caceres wrote:
On Friday, September 6, 2013 at 5:36 PM, Neil Harris wrote:
On 06/09/13 16:34, Gervase Markham wrote:
Data! Sounds like a plan.
Or we could ask our friends at Google or some other search engine to run
a version of our detector over their index and
On Friday, September 6, 2013 at 5:36 PM, Neil Harris wrote:
On 06/09/13 16:34, Gervase Markham wrote:
Data! Sounds like a plan.
Or we could ask our friends at Google or some other search engine to run
a version of our detector over their index and see how often it says
UTF-8
Could you clarify number 2? It's a little dense.
-Jeff
- Original Message -
From: Robert O'Callahan rob...@ocallahan.org
To: Bas Schouten bschou...@mozilla.com
Cc: Jeff Muizelaar jmuizel...@mozilla.com, Vladimir Vukicevic
vladi...@mozilla.com, dev-platform@lists.mozilla.org,
Hi everyone. I wanted to give you all a quick overview of where we are with
our plans to deliver developer tools targeted at web app developers for
Firefox OS and the web app runtimes on android and desktop.
Developer tools support in Firefox OS
We've been hard at work adding developer tools
On 06/09/13 18:28, Boris Zbarsky wrote:
On 9/6/13 1:11 PM, Neil Harris wrote:
Presumably most of that XHTML is being generated by automated tools
Presumably most of that XHTML are tag-soup pages which claim to have
an XHTML doctype. The chance of them actually being valid XHTML is
slim to
On Sat, Sep 7, 2013 at 7:02 AM, Jeff Gilbert jgilb...@mozilla.com wrote:
Could you clarify number 2? It's a little dense.
A better way to state it is this: every layer tree update by the main
thread eventually gets a response in the form of a vsync-driven request to
tick the corresponding
On Fri, Sep 6, 2013 at 2:51 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On some non-main thread:
1. Wait for vsync event
2. Dispatch refresh driver ticks to all windows that don't already have a
pending refresh driver tick unacknowledged by a layer tree update response
3. Wait for N ms,
As I commented in bug 770316, splitmenus aren't really a supported
part of the general platform, and I think we will remove them soon. So
I would discourage you from using them further, if possible :)
Gavin
On Thu, Sep 5, 2013 at 2:42 PM, Jan Odvarko odva...@gmail.com wrote:
Two questions about
On Fri, Sep 6, 2013 at 1:32 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
With the above code I do get an iframe that loads about:about, which
is good. But there's no child process created, and when I inspect the
|remote| attribute of the iframe it is |undefined|, as if something
18 matches
Mail list logo
