RE: XUL splitmenu

2013-09-06 Thread Jan Odvarko 
I see, thanks for the update
Honza

> -Original Message-
> From: gavin.sh...@gmail.com [mailto:gavin.sh...@gmail.com] On Behalf Of
> Gavin Sharp
> Sent: Saturday, September 07, 2013 2:55 AM
> To: Jan Odvarko
> Cc: dev-platform
> Subject: Re: XUL splitmenu
> 
> 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  wrote:
> > Two questions about  element:
> >
> > #1) I wanted to displya a check-box in front of the 
> > element, but setting type="checkbox" and checked="true" doesn't help.
> > Shouldn't this just work? Is this a bug?
> >
> > #2) It looks like that the  element doesn't work on OSX.
> > Correct?
> >
> > Honza
> >
> > ___
> > 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: How to create a child process in a chrome mochitest?

2013-09-06 Thread Gavin Sharp 
On Fri, Sep 6, 2013 at 1:32 PM, Nicholas Nethercote
 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
> prevented it from being set to true.

Note that  elements do not have .remote property
getter/setters, so you need to check e.g.
browser.hasAttribute("remote") rather than browser.remote.

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

Re: XUL splitmenu

2013-09-06 Thread Gavin Sharp 
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  wrote:
> Two questions about  element:
>
> #1) I wanted to displya a check-box in front of the  element,
> but setting type="checkbox" and checked="true" doesn't help.
> Shouldn't this just work? Is this a bug?
>
> #2) It looks like that the  element doesn't work
> on OSX. Correct?
>
> Honza
>
> ___
> 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: vsync proposal

2013-09-06 Thread Robert O'Callahan 
On Fri, Sep 6, 2013 at 2:51 PM, Robert O'Callahan wrote:

> 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, processing any layer-tree updates (where N = vsyncinterval 
> - generously estimated time to composite all windows)
> 4. Composite all updated windows
> 5. Goto 1
>
> This could happen on the compositor thread or some other thread depending
> on how "wait for vsync event" is implemented on each platform.
>

It's worth thinking about what happens if a window misses the Nms deadline,
either because it consistently takes more than Nms to paint or there's just
one slow frame due to GC or something like that.

For values of say N=10ms, vsync period 16ms, and a window paint time of
consistently 12ms, this approach will cut frame rate in half. That's not
what we want.

So we need to modify step 1:
1. Wait for vsync event, processing any layer-tree updates and compositing
those windows
2. Dispatch refresh driver ticks to all windows that got layer tree updates
since the last iteration of step 2
3. Wait for N ms, processing any layer-tree updates (where N =
vsyncinterval - generously estimated time to composite all windows)
4. Composite all windows that either received a layer-tree update or have
some kind of off-main-thread animation
5. Goto 1

This does mean if the window paint time is (e.g.) 12ms and it also has
off-main-thread animations, we composite it twice per frame. I don't see
any way around that.

Now with this, if the window paint time is say 18ms, we still cut the frame
rate in half, and that's still not good. So I think we need to modify this
some more: when we process a layer tree update, if we expected but did not
receive a layer tree update to that window during the previous vsync
interval, dispatch the next refresh driver tick to that window immediately
instead of waiting for the next vsync event. There are some tricky details
to work out though.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: vsync proposal

2013-09-06 Thread Robert O'Callahan 
On Sat, Sep 7, 2013 at 7:02 AM, Jeff Gilbert  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 refresh driver. So, assuming the "non-main thread"
above is the compositor thread, the set of windows composited in step 4 is
the set of windows notified in step 2 in the next iteration.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Detection of unlabeled UTF-8

2013-09-06 Thread Neil Harris 

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 none (though maybe higher than the chance of them being served 
as application/xhtml+xml).


-Boris



Indeed. I suspect in quite a lot of these cases the reason for using an 
XHTML doctype was that XHTML's got an "X", and anything with an "X" 
added has _got_ to be better.


-- XNeil


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

Webapp developer tools status and next steps

2013-09-06 Thread Dave Townsend 
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 actors into the Gecko 26
code in time for the Firefox OS 1.2 branch. We expect to get this all
landed before the merge and following that we'll be landing some more
actors bringing additional features for Firefox OS 1.3.

Firefox OS Simulator

We recently released version 4 of the Firefox OS simulator and version 5 is
in development. This will be the last version that runs Firefox OS 1.1 and
perhaps more importantly the last version that includes the dashboard for
managing apps. Version 5 of the simulator will also only be compatible up
to Firefox 25 as changes to the devtools protocol in Firefox 26 break
things after then. Those wanting to test against Firefox 1.1 will have to
continue using an older version of Firefox, the Firefox 24 ESR release
would work. After this we'll be switching to lighter builds of simulator,
moving all the app management side into the new tool in Firefox...

App Manager (name TBD)

The replacement for the dashboard from simulator is in development and the
first pieces have already landed in Firefox. Flip the
devtools.appmanager.enabled pref to see it in the web development menu.
This simplifies connecting to devices and simulators and listing,
installing and debugging apps. For now the ability to connect to a Firefox
OS device will require an additional add-on which installs a version of the
adb binary. We hope to ship that built into Firefox at a later point. The
App Manager will also eventually have a way of downloading and installing
different versions of simulator to connect to.

Now that the first version has landed and started riding the trains for 26
we'll start working on adding new features that will be supported in
Firefox OS 1.3. Features like mocking web APIs and web activities. We
expect by next February to have support for connecting to and debugging
both Firefox OS 1.2 and 1.3 though the capabilities will differ slightly
between those two versions, as they will continue to do as we add more
capabilities into later versions of Firefox OS.

For now salivate over the screencast of the work:
http://people.mozilla.com/~prouget/appmanager.webm and if you have any
questions please let me know.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: vsync proposal

2013-09-06 Thread Jeff Gilbert 
Could you clarify number 2? It's a little dense. 

-Jeff

- Original Message -
From: "Robert O'Callahan" 
To: "Bas Schouten" 
Cc: "Jeff Muizelaar" , "Vladimir Vukicevic" 
, dev-platform@lists.mozilla.org, avih...@yahoo.com
Sent: Thursday, September 5, 2013 7:51:02 PM
Subject: Re: vsync proposal

I had some off-thread discussion with Bas about lowering latency. We seem
to have agreed on the following plan:

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, processing any layer-tree updates (where N =
vsyncinterval - generously estimated time to composite all windows)
4. Composite all updated windows
5. Goto 1

This could happen on the compositor thread or some other thread depending
on how "wait for vsync event" is implemented on each platform.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*
___
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: PSA: MOZ_STATIC_ASSERT removed in C++ code, replaced by C++11 static_assert

2013-09-06 Thread Jeff Walden 
On 07/30/2013 11:27 AM, Ehsan Akhgari wrote:
> I just landed bug 895322, which removes the MOZ_STATIC_ASSERT macro in C++
> code, and replaces it with the C++11 static_assert keyword.  You should use
> static_assert in C++ code from now on.

A belated note: MOZ_STATIC_ASSERT was valid at top level, and inside method 
bodies.  C++11 static_assert is considered a declaration in the spec, so it's 
valid anywhere a declaration should go.  In particular, it's valid inside class 
bodies, and you no longer need class methods specifically to hold static 
asserts:

accessible/src/generic/Accessible.cpp
3352-Accessible::StaticAsserts() const
3353-{
3354:  static_assert(eLastChildrenFlag <= (2 << kChildrenFlagsBits) - 1,
3355-"Accessible::mChildrenFlags was oversized by 
eLastChildrenFlag!");
3356:  static_assert(eLastStateFlag <= (2 << kStateFlagsBits) - 1,
3357-"Accessible::mStateFlags was oversized by 
eLastStateFlag!");
3358:  static_assert(eLastAccType <= (2 << kTypeBits) - 1,
3359-"Accessible::mType was oversized by eLastAccType!");
3360:  static_assert(eLastAccGenericType <= (2 << kGenericTypesBits) - 1,
3361-"Accessible::mGenericType was oversized by 
eLastAccGenericType!");
3362-}

Usually it doesn't *hurt* to do it this way, except in noise.  But it *does* 
become problematic if the method's in a templated class, because the 
static_asserts only happen if the method is instantiated (i.e. if it's called):

[jwalden@find-waldo-now tmp]$ cat i.cpp 
#include 

template
struct Test
{
  void foo() { static_assert(i != 0, "fail"); }
};

int main()
{
  Test<0> t;
#if FAIL
  t.foo();
#endif
}
[jwalden@find-waldo-now tmp]$ clang++-tip -std=c++11 i.cpp 
[jwalden@find-waldo-now tmp]$ clang++-tip -std=c++11 i.cpp -DFAIL
i.cpp:6:16: error: static_assert failed "fail"
  void foo() { static_assert(i != 0, "fail"); }
   ^ ~~
i.cpp:13:5: note: in instantiation of member function 'Test<0>::foo' requested 
here
  t.foo();
^
1 error generated.

So to avoid this little bit of surprise, you should put your static_asserts 
inside the class you're asserting stuff about, whenever possible.

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

Re: Detection of unlabeled UTF-8

2013-09-06 Thread Marcos Caceres 



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" when our normal algorithm would say something else.
> > 
> > Gerv
> This website has an interesting, and apparently up-to-date set of 
> statistics:
> 


Wait a minute, they also claim that XHTML is used on  54.9% of sites? I'm 
skeptical of their methodology. See:  

http://w3techs.com/technologies/overview/markup_language/all
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Detection of unlabeled UTF-8

2013-09-06 Thread Neil Harris 

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 see how often it says
"UTF-8" when our normal algorithm would say something else.

Gerv

This website has an interesting, and apparently up-to-date set of
statistics:



Wait a minute, they also claim that XHTML is used on  54.9% of sites? I'm 
skeptical of their methodology. See:

http://w3techs.com/technologies/overview/markup_language/all



On reading that, that surprised me too.

However, that doesn't seem too far from this site's estimate for the 
same thing:


http://try.powermapper.com/Stats/HtmlVersions

Presumably most of that XHTML is being generated by automated tools 
whose authors assumed that XHTML represented the "latest and greatest" 
HTML spec, and who it seems are now in the process of transitioning to 
the new latest-and-greatest, HTML 5, as shown by the rising tide of HTML 
5 in the above graph.


-- Neil

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

Re: Deploying more robust hg-git replication for gecko

2013-09-06 Thread Aki Sasaki 
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,
>>> change that if needed. When I add a new repo or a slew of new branches
>>> to convert, the job can take longer to complete, but it typically
>>> finishes in about 6 minutes.
>>
>> Sounds good, that's exactly the same setup and frequency that I have as
>> well.  It seems to be working fine for most people.
> 
> I had the same frequency before, but the problem is that when you are
> trying to push, you are 5 minutes late compared to the others.  It
> happens to me, that I had to rebase multiple times before being able to
> push anything to inbound.
> 
> Since, I changed to a system which is looking every 10s for
> modifications in the pushlogs, then if there is a modification the
> script will update of the modified branch.
> 
> The reasons why I bring the timer so low, is that the pushlog is serve
> through http, and the server is likely to cache it knowing that this is
> used by tbpl (which by the way use https).  I did not do it before
> because "hg id" still implies that we have to establish a secure
> connection.

Sounds like "It seems to be working fine for most people" + it doesn't
work for Nicolas, who has his own solution.  Accurate?


I will be working on reducing the length of the process by parallelizing
what I can, but thought this was at an acceptable-enough level that I
should move towards pushing test-beagle live, and leave further
enhancements + improvements as non-blocking.

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

Re: Detection of unlabeled UTF-8

2013-09-06 Thread Robert Kaiser 

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 at every 
rendered-as-text node/attribute in the DOM tree and run some kind of 
charset detection on it?


May be a dumb idea but might avoid the problem on the parsing level.

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

Rendering meeting Monday 5:30pm PDT

2013-09-06 Thread Milan Sreckovic 
The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm 
PDT.

The next meeting will take place upcoming Monday, September 9th at 5:30 PM 
US/Pacific.  This is the time that's manageable for Taipei, not so good for 
Europe.

Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2013-September-9

San Francisco - Monday, 5:30pm
Winnipeg - Monday, 7:30pm
Toronto - Monday, 8:30pm
GMT/UTC - Tuesday, 0:30
Paris - Tuesday, 2:30am
Taipei - Tuesday, 8:30am
Auckland - Tuesday, 12:30pm

Video conferencing:
Vidyo room Graphics (9366)
https://v.mozilla.com/flex.html?roomdirect.html&key=FILzKzPcA6W2

Phone conferencing:
+1 650 903 0800 x92 Conf# 99366
+1 416 848 3114 x92 Conf# 99366
+1 800 707 2533 (pin 369) Conf# 99366

--
- Milan

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

Re: Detection of unlabeled UTF-8

2013-09-06 Thread Boris Zbarsky 

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 none (though maybe higher than the chance of them being served as 
application/xhtml+xml).


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

Re: Detection of unlabeled UTF-8

2013-09-06 Thread Neil Harris 

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 interesting, and apparently up-to-date set of 
statistics:


http://w3techs.com/technologies/overview/character_encoding/all

Their current top ten encodings, as of today, are:

UTF-8: 76.7%
ISO-8859-1: 11.7%
Windows-1251 (Cyrillic): 2.9%
GB2312 (Chinese): 2.5%
Shift JIS (Japanese): 1.5%
Windows-1252 (superset of ISO-8859-1): 1.4%
GBK (Chinese): 0.7%
ISO-8859-2 (Eastern Europe, Latin script): 0.4%
EUC-JP (Japanese): 0.4%
Windows-1256 (Arabic): 0.4%

Although the exact interpretation of these results is tricky, since they 
don't give their criteria for exactly how they define and detect these 
decodings, if their results are even approximately right, it's pretty 
clear that UTF-8 now dominates the web as the single commonest 
charset/encoding by far.


-- N.

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

Re: Detection of unlabeled UTF-8

2013-09-06 Thread Neil Harris 

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 at every 
rendered-as-text node/attribute in the DOM tree and run some kind of 
charset detection on it?


May be a dumb idea but might avoid the problem on the parsing level.

Robert Kaiser



I think that would create a whole lot more problems than it would fix, 
and would be unworkable in practice.


Charset detection from content is a probabilistic matter at best, and 
treating the document as many small snippets of text would not only 
increase the probability of the detection algorithm getting it wrong for 
each node, but also give a large number of opportunities per page for at 
least one of those detections to go wrong.


-- N.


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

Re: Detection of unlabeled UTF-8

2013-09-06 Thread Adam Roach 

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). There's no good 
way to explain the nuanced implications of security decisions in a way 
that is both accessible to a lay user and concise enough to hold the 
average user's attention.



On Thu, Sep 5, 2013 at 6:15 PM, Adam Roach  wrote:

As to the "why," it comes down to balancing the need to let the publisher
know that they've done something wrong against punishing the user for the
publisher's sins.

Two problems:
  1) The complexity of the platform increases in order to address a fringe case.
  2) Making publishers' misdeeds less severe in the short term makes it
more OK for publishers to engage in the misdeeds, which in the light
of #1 leads to long-term problems. (Consider the character encoding
situation in Japan and how HTML parsing in Japanese Firefox is worse
than in other locales as the result.)


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 as a problem as recently as 
last week. If you think we need to move beyond anecdotes and personal 
experience, let's go ahead and add telemetry to find out how often this 
arises in the field.


Your second point is an argument against automatic correction. Don't get 
me wrong: I think automatic correction leads to innocent publisher 
mistakes that make things worse over the long term. I absolutely agree 
that doing so trades short-term gain for long-term damage. But I'm not 
arguing for automatic correction.


But it's not our job to police the web.

It's our job to... and I'm going to borrow some words here... give users 
"the ability to shape their own experiences on the Internet." You're 
arguing _against_ that for the purposes of trying to control a group of 
publishers who, for whatever reason, either lack the ability or don't 
care enough to fix their content even when their tools clearly tell them 
that their content is broken.


--
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: Detection of unlabeled UTF-8

2013-09-06 Thread Gervase Markham 
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 as a problem as recently as
> last week. If you think we need to move beyond anecdotes and personal
> experience, let's go ahead and add telemetry to find out how often this
> arises in the field.

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to create a child process in a chrome mochitest?

2013-09-06 Thread Tom Schuster 
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  wrote:

> Nicholas Nethercote wrote:
>
>  In theory, this is as easy as  or > remote>, or something like that.  But I've tried about 80 different
>> variations on these, and I cannot get a child process.
>>
>>  Mochitests already run inside a browser, so attempting to nest a child
> browser will fail. Try opening a chrome window with a XUL document
> containing a remote browser element.
>
> --
> Warning: May contain traces of nuts.
>
> __**_
> 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: How to create a child process in a chrome mochitest?

2013-09-06 Thread Neil 

Nicholas Nethercote wrote:


In theory, this is as easy as  or , 
or something like that.  But I've tried about 80 different variations on these, and I 
cannot get a child process.

Mochitests already run inside a browser, so attempting to nest a child 
browser will fail. Try opening a chrome window with a XUL document 
containing a remote browser element.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDownloadManager replaced by Downloads.jsm

2013-09-06 Thread Eric Shepherd 

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 appreciate it when the people who best know 
new features and technologies are active in the documentation process, 
and creating the docs like this is the absolute most effective way to 
do that.


That you also went for it and documented Promise.jsm while you were at 
it is a wonderful bonus.


You win the coveted Hero of the MDN Team award!

--
Eric Shepherd
Developer Documentation Lead
Mozilla
Blog: http://www.bitstampede.com/
Twitter: @sheppy

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

Re: How to create a child process in a chrome mochitest?

2013-09-06 Thread Benjamin Smedberg 

On 9/6/2013 2:32 AM, Nicholas Nethercote wrote:


In theory, this is as easy as  or 
 is what B2G uses. It requires the prefs 
than Kan-Ru mentions.


 is what desktop uses. It does not require 
special prefs that I know of.


--BDS

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

Re: Detection of unlabeled UTF-8

2013-09-06 Thread Henri Sivonen 
On Thu, Sep 5, 2013 at 7:32 PM, Mike Hoye  wrote:
> On 2013-09-05 10:10 AM, Henri Sivonen wrote:
>>
>> It's worth noting that for other classes of authoring errors (except for
>> errors in https deployment) we don't give the user the tools to remedy
>> authoring errors.
>
> Firefox silently remedies all kinds authoring errors.

Silently, yes. I was trying to ask about surfacing error-remedying UI
to the user. We do surface such UI for https deployment errors
inspiring academic papers about how bad it is  that users are exposed
to such UI.

On Thu, Sep 5, 2013 at 9:29 PM, Robert Kaiser  wrote:
> UTF-8 is what is being suggested
> everywhere as the encoding to go with, and as we should be able to detect it
> easily enough, we should do it and switch to it when we find it.

Considering what Aryeh said earlier in this thread, do you have a
suggestion how to do that so that
 1) Incremental parsing and rendering aren't hindered.
AND
 2) The results are deterministic and reliable and don't depend on the
byte position of the first non-ASCII byte in the data stream.
AND
 3) The processing of referenced unlabeled CSS and JavaScript doesn't
have race conditions even with speculative parsing involved, is
unsurprising and doesn't break legacy content.
AND
 4) We don't incur the performance penalty of re-parsing or
re-building the DOM if authors start labeling UTF-8 less due to no
longer having to label.
AND
 5) Side effects of scripts are not effected twice if authors start
labeling UTF-8 less due to no longer having to label.
?

On Thu, Sep 5, 2013 at 6:15 PM, Adam Roach  wrote:
> As to the "why," it comes down to balancing the need to let the publisher
> know that they've done something wrong against punishing the user for the
> publisher's sins.

Two problems:
 1) The complexity of the platform increases in order to address a fringe case.
 2) Making publishers' misdeeds less severe in the short term makes it
more OK for publishers to engage in the misdeeds, which in the light
of #1 leads to long-term problems. (Consider the character encoding
situation in Japan and how HTML parsing in Japanese Firefox is worse
than in other locales as the result.)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
http://hsivonen.iki.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to create a child process in a chrome mochitest?

2013-09-06 Thread 陳侃如 
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  writes:

> Hi,
>
> I want to create a child process in
> toolkit/components/aboutmemory/tests/test_memoryReporters.xul, so I
> can test the cross-process memory reporting.
>
> In theory, this is as easy as  or  remote>, or something like that.  But I've tried about 80 different
> variations on these, and I cannot get a child process.
>
> This is the closest I've got:
>
> remote="true"/>
>
> AIUI, the |html:| prefix and the |="true"| attribute values are
> necessary because this is a XUL file and hence XML.  My 
> element looks like this:
>
>  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul";
> xmlns:html="http://www.w3.org/1999/xhtml";>
>
> 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
> prevented it from being set to true.
>
> What am I doing wrong?  The docs
> (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe and
> https://developer.mozilla.org/en-US/docs/WebAPI/Browser?redirectlocale=en-US&redirectslug=DOM%2FUsing_the_Browser_API
> and https://developer.mozilla.org/en-US/docs/XUL/iframe) make it
> sounds like this should be easy.
>
> Nick
> ___
> 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