Re: HTML mozbrowser frames on desktop Firefox?

[Bobby Holley]

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 the Web in any way, since the cost of even partially-exposing a
non-standard API in Firefox is much higher than in FFOS.

I would also imagine that this may not play well with e10s, so you should
definitely consult IPC wizards and e10s technical leadership before doing
anything in this area.

bholley

On Fri, Jan 8, 2016 at 8:52 AM, Adam Roach  wrote:

> 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
>> 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 turn it on.
>>
>>
>> On Fri, Jan 8, 2016 at 3:31 PM, J. Ryan Stinnett 
>> wrote:
>>
>> (CCing dev-platform as suggested on IRC.)
>>>
>>> On Thu, Jan 7, 2016 at 9:58 PM, J. Ryan Stinnett 
>>> wrote:
>>>
 DevTools is working on rebuilding the responsive design UI in an HTML,
 chrome-scoped page. This page will want to manage child frames to show
 the page content, which could be remote frames. So, I would want to
 use  for cases like these.

 However, I noticed mozbrowser frames are currently preffed off
 (dom.mozBrowserFramesEnabled) on desktop. Is there a reason for this?
 Can it be turned on, or is there some kind of work still needed before
 it is usable?

 I assume we would eventually want to enable this anyway, so that HTML
 frames can be used in the primary browser UI.

 - Ryan

>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
> --
> Adam Roach
> Principal Platform Engineer
> a...@mozilla.com
> +1 650 903 0800 x863
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

wptview [Re: e10s]

[Kalpesh Krishna]

For web-platform-tests there is an additional issue; tests may be enabled
but give a different result in e10s builds compared to non-e10s builds.
Therefore compiling a list of disabled web-platform-tests in e10s is
insufficient to spot all the differences in this case.

Instead, I recommend using the wptview tool which allows comparing the
results of different web-platform-tests runs (or, indeed, any testsuite
that uses structured logging). For people who are not interested in e10s
specifically, this tool may still be useful when trying to examine the
results of web-platform-tests runs.
The tool aims at providing filtering of structured log results, based on
status, path and test type. It takes one or more testsuite_raw.log files (e.g.
wpt_raw.log, mochitest_raw.log) (obtained from Treeherder) and allows us to
compare results, (eg: All tests where results from e10s != results from
non-e10s build). It reads all tests, (including disabled tests).

For example, to compare the W-2 and W-e10s-2 results from a recent run

* Load http://jgraham.github.io/wptview/

* From treeherder download the wpt_raw.log artifacts for a W-2 and W-e10s-2
run on a build you are interested in. For the rest of this example I used
[1] and [2] (loading from the log URL is on the roadmap).

* In the wptview UI click on import, select the log for the W2 run and give
the run a name like "W-2". Do the same for the W-e10s-2 log file. Note that
importing files is still rather slow.
http://ibin.co/2Sjznpoms8BW

* Once the 2 logs have been imported, we get a list of all disabled tests
in the e10s build, along with their results in the non-e10s build using a
"By Result" filter saying "w-e10s-2 is SKIP". A number of test rows are
rendered, each showing the test file, subtest (if any) and the Expected /
Actual STATUS for each of the two runs.
http://ibin.co/2Sk1vaguPyQ8

* If we wish to see all tests having a different status in w-2 and
w-e10s-2, we add a filter like "w-2 is not results from w-e10s-2". Once
again, a number of rows containing the filtered output are rendered.
http://ibin.co/2Sk2R7ngwVWF

Wptview is flexible and allows us to have a number of different complicated
filters. For a demonstration, To obtain tests under /XMLHttpRequest/ where
e10s and non e10s have the same result, and they have a status of ERROR or
TIMEOUT, we need three filters. A path filter saying "Path starts with
XMLHttpRequest", and two status filters saying "w-2 is results from
w-e10s-2" and "w-2 is ERROR or TIMEOUT" (The + symbol adds the OR operator).
http://ibin.co/2SlVPLNSvfnW

wptview also addresses several other use cases that have hitherto required
examining the logs by hand, such as looking for web-platform-tests that
CRASH, looking for tests for a specific feature that don't pass, and
comparing results from Servo and Gecko. Results are stored locally on an
IndexedDB, so one may resume filtering tasks for previously imported logs.
Test results could also be cleared using the "CLEAR ALL" button and started
afresh.

For feature requests and bug reports, please use the github issue tracker
at https://github.com/jgraham/wptview/. If you have any questions, please
ask me, martianwars, or jgraham, on #ateam.

I hope you found this interesting! :)

Cheers!

[1] - W-2 wpt-raw.log


[2] - W-e10s-2 wpt_raw.log


-- 
Kalpesh Krishna,
Sophomore Undergraduate,
Electrical Engineering,
IIT Bombay
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Authentication Working Group

[L. David Baron]

On Thursday 2016-01-07 10:14 -0800, Richard Barnes wrote:
> Obviously, given the earlier FIDO thread here, I think this is good work to
> support.
> 
> I think the charter is in pretty good shape.  The only comment I have is
> that it talks about "attestations" without defining what is being attested.
> This could be addressed with the following change:
> 
> OLD:  "Attestation and signature formats defined for interoperability."
> NEW: "Formats for signed data and verifiable attestations of a signer's
> properties."

OK, I'll plan to submit a vote in support, with the above comment as
a suggested (but not formal objection) change.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Authentication Working Group

[L. David Baron]

On Saturday 2016-01-09 07:22 +1100, L. David Baron wrote:
> On Thursday 2016-01-07 10:14 -0800, Richard Barnes wrote:
> > Obviously, given the earlier FIDO thread here, I think this is good work to
> > support.
> > 
> > I think the charter is in pretty good shape.  The only comment I have is
> > that it talks about "attestations" without defining what is being attested.
> > This could be addressed with the following change:
> > 
> > OLD:  "Attestation and signature formats defined for interoperability."
> > NEW: "Formats for signed data and verifiable attestations of a signer's
> > properties."
> 
> OK, I'll plan to submit a vote in support, with the above comment as
> a suggested (but not formal objection) change.

(And this response is modifiable until the deadline for comments.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML mozbrowser frames on desktop Firefox?

[J. Ryan Stinnett]

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 use
> mozbrowser on Desktop should take extreme care not to accidentally expose it
> to the Web in any way, since the cost of even partially-exposing a
> non-standard API in Firefox is much higher than in FFOS.
>
> I would also imagine that this may not play well with e10s, so you should
> definitely consult IPC wizards and e10s technical leadership before doing
> anything in this area.

Okay, that's good to know. I'll reach out to a more focused group to
have this discussion.

- Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: wptview [Re: e10s]

[Benjamin Smedberg]

On 1/8/2016 3:16 PM, Kalpesh Krishna wrote:

For web-platform-tests there is an additional issue; tests may be enabled
but give a different result in e10s builds compared to non-e10s builds.
Therefore compiling a list of disabled web-platform-tests in e10s is
insufficient to spot all the differences in this case.

What are the implications of this?

The web-platform tests are pass/fail, right? So is it a bug if they pass 
but have different behaviors in e10s and non-e10s mode?


If it is a problem (or a potential problem), who is responsible for 
understanding the problem and fixing it? Should it turn something on 
treeherder red?


--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: wptview [Re: e10s]

[James Graham]

On 08/01/16 22:41, Robert O'Callahan wrote:

On Sat, Jan 9, 2016 at 10:27 AM, Benjamin Smedberg 
wrote:


What are the implications of this?

The web-platform tests are pass/fail, right? So is it a bug if they pass
but have different behaviors in e10s and non-e10s mode?



Yeah, I'm confused.

If a wpt test passes but with different output, then either there is no
problem or the test is incomplete and should be changed.


Maybe I should clarify.

web-platform-tests are slightly different to most tests in that we run 
both tests we currently pass and tests that we currently don't pass. On 
treeherder all we check is that we got the same result in this run as we 
expected on the basis of previous runs. That result might be pass but 
might also be FAIL, ERROR, TIMEOUT, or even CRASH. So they are pass/fail 
from the point of view of "did we meet the expectation value", but the 
expectation value itself might not be a PASS (e.g. expected FAIL got 
PASS would turn treeherder orange, as would expected CRASH got ERROR).


For e10s runs we have the ability to set different expectation values 
than for non-e10s runs. This means that we can continue to run tests 
that behave differently in e10s an only disable unstable ones. This has 
the advantage that we will catch some additional types of regression 
e.g. one that causes a test that PASSes in non e10s, previously FAILed 
in e10s and starts to CRASH in e10s whilst still PASSing in non-e10s. 
These would be missed if we just disabled all tests will differing 
behaviour.


The effect of all of this is that in order to understand what's actually 
needed to bring e10s builds up to par with non-e10s builds you need to 
look at the actual test results rather than just the list of disabled 
tests. I believe that there are both instances of tests that pass in 
non-e10s but not in e10s builds, and the reverse. wptview gives you the 
ability to do that using data directly from treeherder. The actual 
action to take on the basis of this data is obviously something for the 
people working on e10s to determine.


I hope that clarifies things somewhat?

Whilst I am here, it's always worth calling out contributions; wptview 
is a Kalpesh's ateam "Quarter of Contribution" project and he has done 
great work.


P.S. I am currently on leave and will remain so until 18th Jan, so don't 
be surprised if I am unresponsive to follow-ups until then. Ms2ger is a 
good person to ask web-platform-tests questions to in the interim.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dynamic Logging

[Patrick McManus]

On Fri, Jan 8, 2016 at 8:32 PM, Eric Rahm  wrote:

> Why is this so cool? Well now you don't need to restart your browser to
> enable logging [1]. You also don't have to set env vars to enable logging
> [2].
>


epic! thank you.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Dynamic Logging

[Eric Rahm]

Hi Folks-

With bug 1233881  we
landed the ability turn on logging via prefs.

Lets say you have a log module "Foo", if you add a "logging.Foo" pref and
set it to "Debug" you will now see all output from the Foo log module that
is of Debug and higher importance.

Why is this so cool? Well now you don't need to restart your browser to
enable logging [1]. You also don't have to set env vars to enable logging
[2].

There is one caveat: if you don't use LazyLogModule and friends, you don't
get dynamic logging. So go update your loggers!

-e

[1] Okay, this only kind of works right now. You'll still need to set
NSPR_LOG_MODULES="anything_you_want" to see output. Bug 1174972
 will fix this.

[2] If you care about messages during startup you will still need to set
the NSPR_LOG_MODULES env var. Unfortunately it takes time to load the pref
system, and then more time to load your profile.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dynamic Logging

[Mike Hommey]

On Fri, Jan 08, 2016 at 05:32:48PM -0800, Eric Rahm wrote:
> Hi Folks-
> 
> With bug 1233881  we
> landed the ability turn on logging via prefs.
> 
> Lets say you have a log module "Foo", if you add a "logging.Foo" pref and
> set it to "Debug" you will now see all output from the Foo log module that
> is of Debug and higher importance.
> 
> Why is this so cool? Well now you don't need to restart your browser to
> enable logging [1]. You also don't have to set env vars to enable logging
> [2].
> 
> There is one caveat: if you don't use LazyLogModule and friends, you don't
> get dynamic logging. So go update your loggers!

I now wish we had the same for the three or so different logging systems
in use in javascript.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dynamic Logging

[Shih-Chiang Chien]

Cool! Does it also work on content process?

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Fri, Jan 8, 2016 at 5:38 PM, Patrick McManus 
wrote:

> On Fri, Jan 8, 2016 at 8:32 PM, Eric Rahm  wrote:
>
> > Why is this so cool? Well now you don't need to restart your browser to
> > enable logging [1]. You also don't have to set env vars to enable logging
> > [2].
> >
>
>
> epic! thank you.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Authentication Working Group

[Richard Barnes]

You might note that the charter already says "Dependencies exist on
the Credential
Management API ..."
:)

The credentials API defines a framework that allows for multiple types of
credential.  So I think the concept is that this WG is likely to define a
new credential type, as is done in the FIDO input:
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

On Thu, Jan 7, 2016 at 3:52 PM, Jonas Sicking  wrote:

> What is the relationship between this WG and the spec draft at
>
> http://www.w3.org/TR/credential-management-1/
>
> Seems like there's potential for integration between the two?
>
> / Jonas
>
> On Thu, Jan 7, 2016 at 10:14 AM, Richard Barnes 
> wrote:
> > Obviously, given the earlier FIDO thread here, I think this is good work
> to
> > support.
> >
> > I think the charter is in pretty good shape.  The only comment I have is
> > that it talks about "attestations" without defining what is being
> attested.
> > This could be addressed with the following change:
> >
> > OLD:  "Attestation and signature formats defined for interoperability."
> > NEW: "Formats for signed data and verifiable attestations of a signer's
> > properties."
> >
> > On Wed, Jan 6, 2016 at 9:09 PM, L. David Baron 
> wrote:
> >
> >> The W3C is proposing a charter for:
> >>
> >>   Web Authentication Working Group
> >>   http://www.w3.org/2015/12/web-authentication-charter.html
> >>
> https://lists.w3.org/Archives/Public/public-new-work/2015Dec/0010.html
> >>
> >> Mozilla has the opportunity to send comments or objections through
> >> January 25.
> >>
> >> Please reply to this thread if you think there's something we should
> >> say as part of this charter review.
> >>
> >> (It seems likely that we want to support it given that Richard is
> >> involved, and one of the proposed co-chairs.)
> >>
> >> -David
> >>
> >> --
> >> 턞   L. David Baron http://dbaron.org/   턂
> >> 턢   Mozilla  https://www.mozilla.org/   턂
> >>  Before I built a wall I'd ask to know
> >>  What I was walling in or walling out,
> >>  And to whom I was like to give offense.
> >>- Robert Frost, Mending Wall (1914)
> >>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML mozbrowser frames on desktop Firefox?

[Tim Guan-tin Chien]

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 turn it on.


On Fri, Jan 8, 2016 at 3:31 PM, J. Ryan Stinnett  wrote:

> (CCing dev-platform as suggested on IRC.)
>
> On Thu, Jan 7, 2016 at 9:58 PM, J. Ryan Stinnett  wrote:
> > DevTools is working on rebuilding the responsive design UI in an HTML,
> > chrome-scoped page. This page will want to manage child frames to show
> > the page content, which could be remote frames. So, I would want to
> > use  for cases like these.
> >
> > However, I noticed mozbrowser frames are currently preffed off
> > (dom.mozBrowserFramesEnabled) on desktop. Is there a reason for this?
> > Can it be turned on, or is there some kind of work still needed before
> > it is usable?
> >
> > I assume we would eventually want to enable this anyway, so that HTML
> > frames can be used in the primary browser UI.
> >
> > - Ryan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: wptview [Re: e10s]

[Robert O'Callahan]

On Sat, Jan 9, 2016 at 10:27 AM, Benjamin Smedberg 
wrote:

> What are the implications of this?
>
> The web-platform tests are pass/fail, right? So is it a bug if they pass
> but have different behaviors in e10s and non-e10s mode?
>

Yeah, I'm confused.

If a wpt test passes but with different output, then either there is no
problem or the test is incomplete and should be changed.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML mozbrowser frames on desktop Firefox?

[J. Ryan Stinnett]

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 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 the Web in any way, since the cost of even partially-exposing a
>> non-standard API in Firefox is much higher than in FFOS.
>>
>> I would also imagine that this may not play well with e10s, so you should
>> definitely consult IPC wizards and e10s technical leadership before doing
>> anything in this area.
>
> Okay, that's good to know. I'll reach out to a more focused group to
> have this discussion.
>
> - Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dynamic Logging

[Eric Rahm]

Yes, although until bug 1234892 is fixed you'll have to restart the process
for changes to take effect.

On Fri, Jan 8, 2016 at 5:51 PM, Shih-Chiang Chien 
wrote:

> Cool! Does it also work on content process?
>
> Best Regards,
> Shih-Chiang Chien
> Mozilla Taiwan
>
> On Fri, Jan 8, 2016 at 5:38 PM, Patrick McManus 
> wrote:
>
>> On Fri, Jan 8, 2016 at 8:32 PM, Eric Rahm  wrote:
>>
>> > Why is this so cool? Well now you don't need to restart your browser to
>> > enable logging [1]. You also don't have to set env vars to enable
>> logging
>> > [2].
>> >
>>
>>
>> epic! thank you.
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dynamic Logging

[Bobby Holley]

This is incredible - thank you for pushing this through Eric!

In case the implications of this aren't clear to anyone: One big difficulty
with debugging intermittent failures is that enabling logging for the
relevant components can often be too expensive for a try run. The logs can
consume hundreds of megabytes, and quickly hit the TreeHerder limits (at
which point you get nothing). We have the ability to record and upload a
log as a separate artifact, but that's rarely useful because it's difficult
to correlate the NSPR log output with the TestRunner spew in the other file.

When I was working on media stability, I debugged dozens of race conditions
by adding hacky instrumentation to make PR_LOG invoke printf if a certain
script-accessible bit was set, and then retriggering on try until the
failure occurred. This work will make that much more straightforward to do.

Eric, is there an option to make the NSPR log output go directly into the
regular test output?

On Fri, Jan 8, 2016 at 5:32 PM, Eric Rahm  wrote:

> Hi Folks-
>
> With bug 1233881  we
> landed the ability turn on logging via prefs.
>
> Lets say you have a log module "Foo", if you add a "logging.Foo" pref and
> set it to "Debug" you will now see all output from the Foo log module that
> is of Debug and higher importance.
>
> Why is this so cool? Well now you don't need to restart your browser to
> enable logging [1]. You also don't have to set env vars to enable logging
> [2].
>
> There is one caveat: if you don't use LazyLogModule and friends, you don't
> get dynamic logging. So go update your loggers!
>
> -e
>
> [1] Okay, this only kind of works right now. You'll still need to set
> NSPR_LOG_MODULES="anything_you_want" to see output. Bug 1174972
>  will fix this.
>
> [2] If you care about messages during startup you will still need to set
> the NSPR_LOG_MODULES env var. Unfortunately it takes time to load the pref
> system, and then more time to load your profile.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dynamic Logging

[Philip Chee]

On 09/01/2016 09:50, Mike Hommey wrote:
> On Fri, Jan 08, 2016 at 05:32:48PM -0800, Eric Rahm wrote:
>> Hi Folks-
>> 
>> With bug 1233881
>>  we landed
>> the ability turn on logging via prefs.
>> 
>> Lets say you have a log module "Foo", if you add a "logging.Foo"
>> pref and set it to "Debug" you will now see all output from the Foo
>> log module that is of Debug and higher importance.
>> 
>> Why is this so cool? Well now you don't need to restart your
>> browser to enable logging [1]. You also don't have to set env vars
>> to enable logging [2].
>> 
>> There is one caveat: if you don't use LazyLogModule and friends,
>> you don't get dynamic logging. So go update your loggers!
> 
> I now wish we had the same for the three or so different logging
> systems in use in javascript.

I think the Thunderbird version of log4moz supports using logging prefs
in this way since forever. So it's now down to two?

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML mozbrowser frames on desktop Firefox?

[Adam Roach]

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
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 turn it on.


On Fri, Jan 8, 2016 at 3:31 PM, J. Ryan Stinnett  wrote:


(CCing dev-platform as suggested on IRC.)

On Thu, Jan 7, 2016 at 9:58 PM, J. Ryan Stinnett  wrote:

DevTools is working on rebuilding the responsive design UI in an HTML,
chrome-scoped page. This page will want to manage child frames to show
the page content, which could be remote frames. So, I would want to
use  for cases like these.

However, I noticed mozbrowser frames are currently preffed off
(dom.mozBrowserFramesEnabled) on desktop. Is there a reason for this?
Can it be turned on, or is there some kind of work still needed before
it is usable?

I assume we would eventually want to enable this anyway, so that HTML
frames can be used in the primary browser UI.

- Ryan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML mozbrowser frames on desktop Firefox?

[J. Ryan Stinnett]

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
nsFrameLoader::TryRemoteBrowser()[1] which requires the  to be inside chrome docshell, such as the root chrome
document. Since I am working from inside a tab, the page is a content
docshell (even though I still have chrome access to Components, etc.),
so these rules block the remote browser for this case.

 is allowed to work in this situation, so
that is one big reason I'd like to use it.

The other reason I want to use  is that I am
using React to manage the content on the page, and creating XUL
elements from within an HTML page is AFAIK not supported by React, so
you have to do some nasty hacking around to make this work.

I'd really prefer to just use HTML elements in my HTML page if I can manage it!

> 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 turn it on.

Right, I would assume it works fine on desktop from a technical
perspective, since it's used by Mulet and other FxOS simulators that
run on desktop.

[1]: 
https://dxr.mozilla.org/mozilla-central/rev/d4213241bb796fdfa7a5ad4f1989e97b44474364/dom/base/nsFrameLoader.cpp#2250

- Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform