Please use "web-platform-tests --manifest-update" for updating wpt tests

[Jeremy Chen]

Hi all,

For web-platform-test, it seems some people still update manifest.json
manually, instead of running "--manifest-update" mach command. Running
"--manifest-update" assures the manifest to be in lexicographic order;
however, manually updating manifest may sometimes accidentally add test
info into a disordering place. Whenever we're in this disorder issue, we'll
have to create an extra patch to fix this (like [1]). Doing so takes
additional effort for both developers and reviewers, which should be
avoidable. Therefore, I would like to see more people use --manifest-update
instead of updating manifest manually.

BTW, if you find lots of unrelated gunk added to manifest after updating,
probably you've encountered *Bug 1259775*
 as well. This should
only happen after adding reftest files, and a work around is mentioned in
[2].

[1] https://reviewboard.mozilla.org/r/46665/diff/3#index_header
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1259775#c3

Cheers,
Jeremy Chen
Software Engineer, Mozilla Corporation
Tel: +886-2-8786-1100 #285
E-mail: jeremyc...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Telemetry experiments need to be easier (on Nightly)

[Jet Villegas]

+1 for streamlining Telemetry deployment

I think we'd still want to:
1. broadcast when experiments are shipping, with a specific start/end/goal,
and what data is collected
2. define scope: Nightly/Aurora/Beta (with a higher approval bar for each,)
+ Desktop/Mobile/Other
3. track bugs that distinguish the experiment and control group

--Jet


On Wed, Apr 20, 2016 at 4:43 AM, Kartikaya Gupta  wrote:

> (Cross-posted to dev-platform and release-management)
>
> Hi all,
>
> Not too long ago I ran a telemetry experiment [1] to figure out how to
> tune some of our code to get the best in-the-wild behaviour. While I
> got the data I wanted, I found the process of getting the experiment
> going to be very heavyweight as it involved getting all sorts of
> approvals and reviews. Going through that process was more
> time-consuming than I would like, and it has put me off from doing
> further experiments of a similar nature. However, this means that the
> decisions I make are going to be less data driven and more guesswork,
> which is not good for obvious reasons.
>
> What I would like to see is a simplified process for telemetry
> experiments on Nightly, making it easier to flip a pref on 50% of the
> population for a week or two and get some useful data out of it. It
> seems to me that many of the approvals (QA, RelMan, Legal, Product)
> should not really be needed for this kind of simple temporary
> pref-flip, assuming the necessary data collection mechanisms are
> already in the code. Does anybody have any objections to this, or have
> other suggestions on how to streamline this process a bit more?
>
> To be clear, I'm not suggesting we do away with these approvals
> entirely, I just want to see more nuance in the process to determine
> when they are *really* required, so that they don't slow us down
> otherwise.
>
> Cheers,
> kats
>
> [1] https://wiki.mozilla.org/Telemetry/Experiments
> ___
> 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: Moving XP to ESR?

[Makoto Kato]

On 2016/04/20 5:14, Nils Ohlmeier wrote:



On Apr 18, 2016, at 09:56, Milan Sreckovic  wrote:

What’s the “XP tax”?  Graphics usually tries to simplify the playing field as 
much as possible, but I can’t say that XP has been causing any trouble, or that 
we have been getting too many XP specific problems (certainly fewer than 
Windows 10 :)


Well as we still have to compile for XP there are certain API’s which we can’t 
use like here:
https://dxr.mozilla.org/mozilla-central/source/media/mtransport/third_party/nICEr/src/stun/addrs.c#228

The good news is that dxr does not find anything using IsXPSP3OrLater(). But 
this looks like we have a bit of version specific code in our tree:
https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true


You should query using IsWin2003OrLater() instead.

Also, if we support Vista+ only, we can remove some LoadLibrary() to use 
Vista+ API.



-- Makoto

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

Re: Moving XP to ESR?

[yuhongbao_386]

On Tuesday, April 19, 2016 at 1:20:56 PM UTC-7, Ted Mielczarek wrote:
> On Tue, Apr 19, 2016, at 04:14 PM, Nils Ohlmeier wrote:
> > The good news is that dxr does not find anything using IsXPSP3OrLater().
> > But this looks like we have a bit of version specific code in our tree:
> > https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true
> 
> FYI, the "XP" here means "cross-platform", and XP_WIN is set whenever
> we're building for Windows.
> 
> 
> > And on top of that come the costs for maintaining XP machines as part of
> > the treeherder setup.
> > 
> > So it is not easy to quantify, but there is a "XP tax" we pay.
> 
> This is true. We hit this with toolchain support, we're actively jumping
> through hoops to continue targeting XP with newer versions of MSVC.
> 
> -Ted

That is why I asked about killing XP SP2 in the first place. This brings it in 
line with what MS officially supported in VS2013 and VS2015. I wonder how much 
of the marketshare is likely XP SP2.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mach command aliases and runtime configuration

[dewqazxc]

Wow, these features look great! Is it possible to release a new version of mach 
on PyPi? I use mach for a couple projects and it'd be great if I could just pip 
install it instead of vendoring it everywhere. Thanks!

On Tuesday, April 12, 2016 at 9:09:14 PM UTC-4, Andrew Halberstadt wrote:
> Hey all, bug 1255450 has landed which means..
> 
> For mach users:
> You can now create a machrc (or .machrc) file in the following locations:
> * $MACHRC
> * ~/.mozbuild
> * topsrcdir
> 
> In the future, individual commands may implement their own settings, but
> for now a single section called 'alias' is implemented in mach core. You
> can use 'alias' to provide defaults, or create an entirely new command, e.g:
> 
> [alias]
> mochitest = mochitest --disable-e10s
> browser = mochitest -f browser
> 
> To see a list of all implemented settings, you can run:
> ../mach settings -l
> 
> 
> For mach command developers:
> You can now provide configuration for your command. See here for
> information how:
> http://gecko.readthedocs.org/en/latest/python/mach/settings.html#defining-settings
> 
> Let me know if anything isn't working as expected.
> 
> -Andrew

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

Re: Intent to ship: Element.animate

[bbirtles]

On Tuesday, 19 April 2016 22:03:48 UTC+9, smaug  wrote:
> > This is a temporary situation because I don't want to have to back out the 
> > whole Element.animate feature due to compat issues from the 'Animation'
> > interface name. After we have shipped Element.animate we can ship the 
> > Animation constructor behind a different pref.
> Why would you need to backout animate() if the interface was 
> [NoInterfaceObject] ?

This was referring to the alternative of shipping the constructor under the 
same pref as the rest of the Element.animate implementation. If we do that and 
compatibility issues with 'Animation' arise late in the game, we'd have to turn 
off the pref and effectively unship the whole Element.animate feature.


> So could we ship constructor + removing [NoInterfaceObject] as a separate 
> step, not when shipping this initial API? And have [NoInterfaceObject] until 
> that. If we're worried about web-compatibility, the API spec editors should 
> consider changing the spec to be more likely web-compatible, and better to 
> do that before anyone supports the constructor (since I assume it might mean 
> changing the interface name)

We could, however we have quite a few tests that rely on this constructor so 
we'd end up being unable to test a lot of things. I wouldn't want to make it 
[NoInterfaceObject] on trunk, at least, but perhaps we could do that on 
aurora/beta, for example.

If we do discover compatibility issues, I'll gladly update the spec. And just 
to clarify, there are no specific compatibility issues that I am aware of--just 
the fact the Animation is a fairly generic name.


At this point it seems like it depends on how likely we are to hit 
compatibility issues. I'll see if the blink folks have any data on this. If it 
seems like the compatibility risk is low, then we should just ship the 
constructor from the start and take the risk that we might have to disable 
Element.animate.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Telemetry experiments need to be easier (on Nightly)

[Kartikaya Gupta]

(Cross-posted to dev-platform and release-management)

Hi all,

Not too long ago I ran a telemetry experiment [1] to figure out how to
tune some of our code to get the best in-the-wild behaviour. While I
got the data I wanted, I found the process of getting the experiment
going to be very heavyweight as it involved getting all sorts of
approvals and reviews. Going through that process was more
time-consuming than I would like, and it has put me off from doing
further experiments of a similar nature. However, this means that the
decisions I make are going to be less data driven and more guesswork,
which is not good for obvious reasons.

What I would like to see is a simplified process for telemetry
experiments on Nightly, making it easier to flip a pref on 50% of the
population for a week or two and get some useful data out of it. It
seems to me that many of the approvals (QA, RelMan, Legal, Product)
should not really be needed for this kind of simple temporary
pref-flip, assuming the necessary data collection mechanisms are
already in the code. Does anybody have any objections to this, or have
other suggestions on how to streamline this process a bit more?

To be clear, I'm not suggesting we do away with these approvals
entirely, I just want to see more nuance in the process to determine
when they are *really* required, so that they don't slow us down
otherwise.

Cheers,
kats

[1] https://wiki.mozilla.org/Telemetry/Experiments
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving XP to ESR?

[Kyle Huey]

On Tue, Apr 19, 2016 at 1:20 PM, Ted Mielczarek  wrote:

> On Tue, Apr 19, 2016, at 04:14 PM, Nils Ohlmeier wrote:
> > The good news is that dxr does not find anything using IsXPSP3OrLater().
> > But this looks like we have a bit of version specific code in our tree:
> >
> https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true
>
> FYI, the "XP" here means "cross-platform", and XP_WIN is set whenever
> we're building for Windows.
>
>
> > And on top of that come the costs for maintaining XP machines as part of
> > the treeherder setup.
> >
> > So it is not easy to quantify, but there is a “XP tax” we pay.
>
> This is true. We hit this with toolchain support, we're actively jumping
> through hoops to continue targeting XP with newer versions of MSVC.


We jump through some hoops to support things like Linux and Mac too, and
those platforms combined have far fewer users than XP.

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

Re: Moving XP to ESR?

[Ted Mielczarek]

On Tue, Apr 19, 2016, at 04:14 PM, Nils Ohlmeier wrote:
> The good news is that dxr does not find anything using IsXPSP3OrLater().
> But this looks like we have a bit of version specific code in our tree:
> https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true

FYI, the "XP" here means "cross-platform", and XP_WIN is set whenever
we're building for Windows.


> And on top of that come the costs for maintaining XP machines as part of
> the treeherder setup.
> 
> So it is not easy to quantify, but there is a “XP tax” we pay.

This is true. We hit this with toolchain support, we're actively jumping
through hoops to continue targeting XP with newer versions of MSVC.

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

Re: Moving XP to ESR?

[Nils Ohlmeier]

> On Apr 18, 2016, at 09:56, Milan Sreckovic  wrote:
> 
> What’s the “XP tax”?  Graphics usually tries to simplify the playing field as 
> much as possible, but I can’t say that XP has been causing any trouble, or 
> that we have been getting too many XP specific problems (certainly fewer than 
> Windows 10 :)

Well as we still have to compile for XP there are certain API’s which we can’t 
use like here:
https://dxr.mozilla.org/mozilla-central/source/media/mtransport/third_party/nICEr/src/stun/addrs.c#228

The good news is that dxr does not find anything using IsXPSP3OrLater(). But 
this looks like we have a bit of version specific code in our tree:
https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true

And on top of that come the costs for maintaining XP machines as part of the 
treeherder setup.

So it is not easy to quantify, but there is a “XP tax” we pay.

Regards
  Nils


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: HTML5 and tags

[Boris Zbarsky]

On 4/19/16 2:44 PM, Tantek Çelik wrote:

The key question to consider about delaying |summary::marker| support
is whether or not we (e.g. you) think the spec for ::marker is
"stable" and "good" enough to ship.


The key question before that one is whether we want to block shipping 
details and summary on the entirety of ::marker support.  Because we do 
NOT want to ship parsing for ::marker while only supporting it for 
summary and not in general


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

Re: Intent to Ship: HTML5 and tags

[Tantek Çelik]

On Tue, Apr 19, 2016 at 12:00 PM, Boris Zbarsky  wrote:
> On 4/19/16 2:44 PM, Tantek Çelik wrote:
>>
>> The key question to consider about delaying |summary::marker| support
>> is whether or not we (e.g. you) think the spec for ::marker is
>> "stable" and "good" enough to ship.
>
>
> The key question before that one is whether we want to block shipping
> details and summary on the entirety of ::marker support.  Because we do NOT
> want to ship parsing for ::marker while only supporting it for summary and
> not in general

Agreed. I'm assuming that our current ::-moz-list-bullet support (as
noted previously) does not (yet?) implement what we'd need for the
entirety of ::marker support.

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

Re: Intent to ship: ParentNode.prepend(), ParentNode.append(), ChildNode.before(), ChildNode.after(), ChildNode.replaceWith()

[Boris Zbarsky]

On 4/19/16 1:43 PM, Mike Taylor wrote:

Given that 48 moves to Dev Edition in ~1 week, is there any reason to
not wait for the 49 cycle to let it bake a full Nightly cycle (and
potentially let us find compat bustage)?


That doesn't seem unreasonable to me.

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

Re: Intent to Ship: HTML5 and tags

[Tantek Çelik]

On Tue, Apr 19, 2016 at 8:41 AM, Ting-Yu Lin  wrote:
> To summarize the feedback so far, I'd still like to ship  and
>  without |summary::marker| because
>
> 1) No other browsers support summary::marker yet.

This is a reason to ship *with* it IMO, per showing standards
leadership, something Firefox is known for, leading the open (rather
than prefixed) web and all that.


> 2) From the webcompat point of view, even if we support summary::marker,
> our usage to customize the triangle will still be different from the
> |summary::-webkit-details-marker| usage on Blink/Webkit. So implementing
> ::marker does not solve the webcompat issue.

This is a normal transition phase in the path towards developers using
standards-based properties (border-radius etc. history has plenty of
examples). Not a reason not to ship.


> 3) The marker (triangle) is still stylable without |summary::marker|.
> Author could change the triangle via |summary { list-style-type: xxx}| or
> use pseudo element |summary::-moz-list-bullet| to add more css rules.

It's good that we have a prefixed alternative (that does not depend on
someone else's prefix).


The key question to consider about delaying |summary::marker| support
is whether or not we (e.g. you) think the spec for ::marker is
"stable" and "good" enough to ship.

That's a judgment call, and I'd like to know your opinion of that.

> Ting-Yu

Thanks,

Tantek


> On Thu, Apr 14, 2016 at 3:53 PM, Ting-Yu Lin  wrote:
>
>> As of Firefox 48 I intent to ship HTML5  and  tags on
>> all platforms.  The features has been developed behind pref
>> "dom.details_element.enabled", and had been enabled on non-release build in 
>> bug
>> 1241750 
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=ship-details-summary
>> Link to standard:
>> https://html.spec.whatwg.org/multipage/forms.html#the-details-element
>>
>> This feature was previously discussed in this "intent to implement" thread:
>>
>> https://groups.google.com/d/msg/mozilla.dev.platform/b0UMDIasfq8/tW49QLgCBwAJ
>>
>> One major concern in the "intent to implement" discussion is the ability
>> to style the summary disclosure triangle.  Currently summary has default
>> style "display: list-item", so we can style the triangle via the pseudo
>> element |summary::-moz-list-bullet| like |li::-moz-list-bullet|.
>>
>> The open question is that do we want to make it prefect to implement
>> |summary::marker| (Bug 1221416
>> ) before shipping,
>> which requires more effort to implement a complete support for ::marker
>> pseudo element (Bug 205202
>> ). If not, we can
>> ship it in Firefox 48. Otherwise this feature might skip one or two
>> releases.
>>
>> Please give me some feedbacks. Thanks.
>>
>> Ting-Yu Lin (:TYLin)
>>
>>
> ___
> 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: Intent to ship: ParentNode.prepend(), ParentNode.append(), ChildNode.before(), ChildNode.after(), ChildNode.replaceWith()

[Mike Taylor]

On 4/19/16 9:13 AM, Boris Zbarsky wrote:

On 4/19/16 3:53 AM, Florin Mezei wrote:

Sounds like this may cause WebCompatibility issues?
How worried are we about this?


Mildly but not desperately.


Given that 48 moves to Dev Edition in ~1 week, is there any reason to 
not wait for the 49 cycle to let it bake a full Nightly cycle (and 
potentially let us find compat bustage)?



Can we mitigate this through testing?


Hard to say.

We could try to mitigate through searching web content for the relevant
method names, but I believe that was already done when writing the spec.
   I could be wrong, of course

Past that, I'm not sure how to design a test plan that would catch
issues, if any, here.  :(


Stuff like this is easy to test for once we know what breaks. It's 
really hard to predict what weird usage in the wild might break this 
though...


--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

On 4/19/16 1:58 AM, Panos Astithas wrote:

Why should we be the ones to take the web compat hit on this?

>
> is the fundamentally biggest issue.
>

I realize I'm late to this thread and the discussion has moved the original
proposal towards something more refined and hence more likely to succeed,
but I'd still like to make a case for this tradeoff:

We should be the ones doing this, because we want to be known as the most
secure, most private browser.

This is isn't an easy position to reach or maintain. It's not as clear-cut
as the fastest browser, or the less memory-demanding browser, but it is one
we have identified as holding a competitive advantage for.


The challenge is that users experience broken websites (web compat) 
firsthand, but privacy and security are invisible.

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

Intent to Implement: requestIdleCallback

[Andreas Farre]

Summary:
Add an API on Window for requesting a callback when the user agent is
idle.

With requestIdleCallback web developers will be able to schedule
background computation tasks on the event loop that has a better
chance of not interfering with other more time-critical operations.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1198381

Link to standard: https://w3c.github.io/requestidlecallback/

Platform coverage: Android, Desktop

Estimated or target release: Firefox 50

Preference behind which this will be implemented:
dom.requestIdleCallback.enabled

Do other browser engines implement this:
* Blink: shipped since Chrome 47[1]
* Edge: no, but publicly supported[2]

[1]
https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
[2] https://www.chromestatus.com/feature/5572795866021888
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Milan Sreckovic]

Release engineering is working on this decision, stay tuned.
—
- Milan



> On Apr 19, 2016, at 12:02 , Nicolas Silva  wrote:
> 
> Re-re-ping.
> Being able to use a more recent standard library would simplify a lot of
> things on our end. For example updating 3rd party libraries such as
> skia, which depends on a modern stl, is a pain, and there are plenty of
> other examples.
> 
> Cheers,
> 
> Nical
> 
> On Mon, Apr 4, 2016, at 07:33 PM, a...@imgland.xyz wrote:
>> Doesn't hombrew provide a version of g++ that includes c++11
>> 
>> 04.04.2016, 18:12, "Nathan Froyd" :
>>> Re-ping on this thread. It would be really useful to have a decision
>>> one way or the other for figuring out exactly how a C++11 STL on OS X
>>> is going to work.
>>> 
>>> -Nathan
>>> 
>>> On Thu, Mar 24, 2016 at 12:51 PM, Ralph Giles  wrote:
  Discussion seems to have wound down. Is there a decision on this?
 
   -r
  ___
  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
>> ___
>> 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

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Nicolas Silva]

Re-re-ping.
Being able to use a more recent standard library would simplify a lot of
things on our end. For example updating 3rd party libraries such as
skia, which depends on a modern stl, is a pain, and there are plenty of
other examples.

Cheers,

Nical

On Mon, Apr 4, 2016, at 07:33 PM, a...@imgland.xyz wrote:
> Doesn't hombrew provide a version of g++ that includes c++11
> 
> 04.04.2016, 18:12, "Nathan Froyd" :
> > Re-ping on this thread. It would be really useful to have a decision
> > one way or the other for figuring out exactly how a C++11 STL on OS X
> > is going to work.
> >
> > -Nathan
> >
> > On Thu, Mar 24, 2016 at 12:51 PM, Ralph Giles  wrote:
> >>  Discussion seems to have wound down. Is there a decision on this?
> >>
> >>   -r
> >>  ___
> >>  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
> ___
> 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: Intent to Ship: HTML5 and tags

[Ting-Yu Lin]

To summarize the feedback so far, I'd still like to ship  and
 without |summary::marker| because

1) No other browsers support summary::marker yet.
2) From the webcompat point of view, even if we support summary::marker,
our usage to customize the triangle will still be different from the
|summary::-webkit-details-marker| usage on Blink/Webkit. So implementing
::marker does not solve the webcompat issue.
3) The marker (triangle) is still stylable without |summary::marker|.
Author could change the triangle via |summary { list-style-type: xxx}| or
use pseudo element |summary::-moz-list-bullet| to add more css rules.

Ting-Yu

On Thu, Apr 14, 2016 at 3:53 PM, Ting-Yu Lin  wrote:

> As of Firefox 48 I intent to ship HTML5  and  tags on
> all platforms.  The features has been developed behind pref
> "dom.details_element.enabled", and had been enabled on non-release build in 
> bug
> 1241750 
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=ship-details-summary
> Link to standard:
> https://html.spec.whatwg.org/multipage/forms.html#the-details-element
>
> This feature was previously discussed in this "intent to implement" thread:
>
> https://groups.google.com/d/msg/mozilla.dev.platform/b0UMDIasfq8/tW49QLgCBwAJ
>
> One major concern in the "intent to implement" discussion is the ability
> to style the summary disclosure triangle.  Currently summary has default
> style "display: list-item", so we can style the triangle via the pseudo
> element |summary::-moz-list-bullet| like |li::-moz-list-bullet|.
>
> The open question is that do we want to make it prefect to implement
> |summary::marker| (Bug 1221416
> ) before shipping,
> which requires more effort to implement a complete support for ::marker
> pseudo element (Bug 205202
> ). If not, we can
> ship it in Firefox 48. Otherwise this feature might skip one or two
> releases.
>
> Please give me some feedbacks. Thanks.
>
> Ting-Yu Lin (:TYLin)
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship: HTML5 and tags

[Ting-Yu Lin]

On Tue, Apr 19, 2016 at 10:15 PM, Boris Zbarsky  wrote:

> On 4/19/16 1:09 AM, Ting-Yu Lin wrote:
>
>> Yes.  supports the same set of "list-style-type" property values
>> as  because our default style for  is "display: list-item".
>>
>
> OK.  And the "counter" involved has the value 0, right?


Yes. We skip incrementing the counter for summary in
nsBlockFrame::RenumberListsFor()
.


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

Re: Intent to ship: Element.animate

[smaug]

On 04/19/2016 04:03 PM, smaug wrote:

On 04/19/2016 03:29 AM, bbirt...@mozilla.com wrote:

On Tuesday, 19 April 2016 02:23:54 UTC+9, smaug  wrote:

On 04/18/2016 05:12 AM, Brian Birtles wrote:

In Firefox 48 I intend to turn Element.animate on by default.

We have been developing the Web Animations API behind the 
dom.animations-api.core.enabled preference and have introduced the
dom.animations-api.element-api.enabled preference for the subset of the API 
that we intend to ship at this time.

Chrome have been shipping a very similar subset of the API starting with Chrome 
36[1] and have recently updated their implementation to match
the subset we plan to ship.[2]

WebKit[3] and Edge[4] both list this as "under consideration" although some 
implementation work has begun in WebKit.[5]

This feature was previously discussed in this "intent to implement" thread:
https://groups.google.com/d/topic/mozilla.dev.platform/3EXBgp26rJs/discussion

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1245000 
Link to standard:
https://w3c.github.io/web-animations/#dom-animatable-animate

The subset of the API we intend to ship is described in the bug above, a 
summary of which I have copied to the end of this mail. We do not
intend to ship the 'finished' promise at this time due to concern that this 
should use a cancelable promise.[6]


Does blink ship 'finished' promise?


No. I've just discussed with them and we will also not ship the 'ready' promise 
either, for similar reasons.


Are there good wpt tests where we pass the same tests as other implementers?


Yes. We've contributed a number of tests to wpt and the Chrome team are running 
them against blink and addressing issues that arise. We still have
more tests to contribute though and a few of us are spending a lot of time on 
that at the moment.


// 'Animation' will not be exposed on the global unless Element.animate is 
called

What does this mean? Per spec 'Animation' should be exposed in the global.


Full details are in bug 1245000 from comment 9 onwards 
(https://bugzilla.mozilla.org/show_bug.cgi?id=).

Initially we would like to release Animation as [NoInterfaceObject] because of 
compat concerns that other libraries might be using 'Animation'.
Blink currently ships with [NoInterfaceObject] so we don't know yet if this 
interface name is Web compatible.

(Unlike blink, however, we have implemented the Animation constructor and, 
per-spec, implemented Element.animate() in terms of that constructor.
Hence the slightly odd situation where Animation is not initially on the global 
but might be added if you call Element.animate().)

That doesn't sound like a behavior we should ship. Either make it 
[NoInterfaceObject] or normal interface.
And if it needs to be [NoInterfaceObject], constructor shouldn't be supported.



This is a temporary situation because I don't want to have to back out the 
whole Element.animate feature due to compat issues from the 'Animation'
interface name. After we have shipped Element.animate we can ship the Animation 
constructor behind a different pref.

Why would you need to backout animate() if the interface was 
[NoInterfaceObject] ?


So could we ship constructor + removing [NoInterfaceObject] as a separate step, 
not when shipping this initial API? And have [NoInterfaceObject] until
that. If we're worried about web-compatibility, the API spec editors should 
consider changing the spec to be more likely web-compatible, and better to
do that before anyone supports the constructor (since I assume it might mean 
changing the interface name)



In other words, ok to ship from here, but not with the odd [NoInterfaceObject] 
+ constructor setup.






-Olli




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

Re: Intent to Ship: HTML5 and tags

[Boris Zbarsky]

On 4/19/16 1:09 AM, Ting-Yu Lin wrote:

Yes.  supports the same set of "list-style-type" property values
as  because our default style for  is "display: list-item".


OK.  And the "counter" involved has the value 0, right?

-Boris

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

Re: Intent to ship: ParentNode.prepend(), ParentNode.append(), ChildNode.before(), ChildNode.after(), ChildNode.replaceWith()

[Boris Zbarsky]

On 4/19/16 10:17 AM, Aryeh Gregor wrote:

Couldn't we add telemetry probes to alert when they hit circumstances
that would cause a problem?


I have no idea until we come up with a possible list of such 
circumstances...


But the most obvious failure mode is a library that does something like:

  if (!("append" in document)) {
// define its own append
  }

adding a telemetry probe for this would be fairly hard, since it would 
need to hook into an operation deep in the JS engine, and one that we 
have multiple codepaths for, some of which are not trivial to change 
(interp and jits).  :(


-Boris

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

Re: Intent to ship: ParentNode.prepend(), ParentNode.append(), ChildNode.before(), ChildNode.after(), ChildNode.replaceWith()

[Aryeh Gregor]

On Tue, Apr 19, 2016 at 5:13 PM, Boris Zbarsky  wrote:
> We could try to mitigate through searching web content for the relevant
> method names, but I believe that was already done when writing the spec.  I
> could be wrong, of course
>
> Past that, I'm not sure how to design a test plan that would catch issues,
> if any, here.  :(

Couldn't we add telemetry probes to alert when they hit circumstances
that would cause a problem?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: ParentNode.prepend(), ParentNode.append(), ChildNode.before(), ChildNode.after(), ChildNode.replaceWith()

[Boris Zbarsky]

On 4/19/16 3:53 AM, Florin Mezei wrote:

Sounds like this may cause WebCompatibility issues?


In theory, yes.  We've tried to mitigate to some extent by making these 
[Unscopable], which should prevent issues from bareword usage in event 
handler attributes, at least.


But if some library defines methods with these names on nodes, there 
could be problems.



How worried are we about this?


Mildly but not desperately.


Can we mitigate this through testing?


Hard to say.

We could try to mitigate through searching web content for the relevant 
method names, but I believe that was already done when writing the spec. 
 I could be wrong, of course


Past that, I'm not sure how to design a test plan that would catch 
issues, if any, here.  :(


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

Re: Dump frame tree in real time

[Gijs Kruitbosch]

On 19/04/2016 14:41, Jip de Beer wrote:

I followed your steps exactly and uses this code to add a canvas on a page with 
jQuery:

 var myCanvas = document.createElement('canvas');
 var width = $(document).width()
 myCanvas.width = width;
 var height = $(document).height()
 myCanvas.height = height;
 var ctx = myCanvas.getContext("2d");
 ctx.drawWindow(window, 0, 0, width, height, "rgba(0, 0, 0, 0)");
 console.log(myCanvas.toDataURL());

Result:
TypeError: ctx.drawWindow is not a function

I'm currently trying to figure out how to make Firefox render the entire page 
the whole time.


drawWindow is a privileged API and you would need to use an add-on or 
Firefox code to call it: 
https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawWindow


~ Gijs

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

Re: Dump frame tree in real time

[Jip de Beer]

I followed your steps exactly and uses this code to add a canvas on a page with 
jQuery:

var myCanvas = document.createElement('canvas');
var width = $(document).width()
myCanvas.width = width;
var height = $(document).height()
myCanvas.height = height;
var ctx = myCanvas.getContext("2d");
ctx.drawWindow(window, 0, 0, width, height, "rgba(0, 0, 0, 0)");
console.log(myCanvas.toDataURL());

Result:
TypeError: ctx.drawWindow is not a function

I'm currently trying to figure out how to make Firefox render the entire page 
the whole time.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Why do we still need to include Qt widget in mozilla-central?

[Wolfgang Rosenauer]

Hi,

for quite some time I'm not really working with Qt anymore. So from my
very own perspective I have to say I cannot care about it anymore
realistically. So if other people are caring and want to become peers it
would even be better for everyone to remove myself from the module.

Wolfgang

Am 18.04.2016 um 22:54 schrieb Kevin Brosnan:
> I don't know if Oleg (Romaxa) is still interested in this work. He was
> doing work for Nokia's MeGo platform when the code was added. MeGo was
> shut down by Nokia. Sailfish OS is the continuation but I don't know of
> any attempt to get Firefox running on Sailfish. Wolfgang is a long time
> Mozilla/SUSE contributor. Doug was a lead engineer on the mobile project
> at the time of the code addition. Now he is managing a platform
> engineering group. I don't think he has any attachment to this code.
> CC'ed them on this thread for comment.
> 
> Kevin
> 
> On Mon, Apr 18, 2016 at 11:24 AM, Jim Blandy  > wrote:
> 
> Where is this work taking place? Would it be possible for you to work
> directly in mozilla-central?
> 
> Looking at the hg history of the the widget/qt subdirectory, all the
> changes I see there are Masayuki updating it for changes elsewhere, and
> people making tree-wide changes that have nothing to do with Qt.
> 
> So, like any other directory would, this code is creating work for other
> engineers. It needs to have someone responsible for it who actually
> cares
> whether it works or not.
> 
> According to the module list at:
> 
> https://wiki.mozilla.org/Modules/All
> 
> The owner of widget/qt is Oleg Romashin, and the peers are Wolfgang
> Rosenauer and Doug Turner. Is this information current?
> 
> 
> 
> 
> On Sun, Apr 17, 2016 at 8:12 AM, Raine Mäkeläinen <
> raine.makelai...@gmail.com > wrote:
> 
> > I think that in this context we are talking about mozilla/widget/qt/*
> > components and yes we're using those in our Gecko build. We don't use
> > QWidgets for Sailfish Browser. User interface of the Sailfish
> Browser is
> > written with Qt QML.
> >
> > There is more info in the embedding wiki [1] and Dmitry's blog [2].
> > Rendering pipeline has changed after Dmitry's blog post but
> otherwise quite
> > close to the current state.
> >
> > [1]
> > https://wiki.mozilla.org/Embedding/IPCLiteAPI
> >
> > [2]
> > http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html
> >
> > -Raine
> >
> > 2016-04-14 20:38 GMT+03:00 Henri Sivonen  >:
> >
> >> Added Raine Mäkeläinen, who has been committing to qtmozembed
> lately, to
> >> CC.
> >>
> >> On Thu, Apr 14, 2016 at 1:51 AM, Jim Blandy  > wrote:
> >> > On Tue, Apr 12, 2016 at 4:27 AM, Henri Sivonen
> mailto:hsivo...@hsivonen.fi>>
> >> wrote:
> >> >>
> >> >> On Tue, Apr 12, 2016 at 7:45 AM, Masayuki Nakano <
> >> masay...@d-toybox.com >
> >> >> wrote:
> >> >> > So, my question is, why do we still have Qt widget in
> >> mozilla-central?
> >> >> > What
> >> >> > the reason of keeping it in mozilla-central?
> >> >>
> >> >> My understanding is that
> >> >> https://git.merproject.org/mer-core/qtmozembed/ still uses it.
> As we
> >> >> are figuring out how to be more embeddable (see
> >> >> https://medium.com/@david_bryant/embed-everything-9aeff6911da0
> ), it's
> >> >> probably a bad time to make life hard for an existing embedding
> >> >> solution.
> >> >
> >> >
> >> > This doesn't really answer the question. We can't have code in
> tree that
> >> > isn't tested, and isn't used, and has nobody responsible for it.
> >> >
> >> > If someone is willing to fix it up and get it tested and
> included in the
> >> > continuous integration process, then that's fine. But "someone
> might
> >> want to
> >> > use it in the future" can't possibly be a legit reason to keep
> >> substantial
> >> > bits of code in the tree.
> >>
> >> It looked to me like the code is being used *now*.
> >>
> >> Raine, does qtmozembed use the Qt widget code from mozilla-central?
> >>
> >> --
> >> Henri Sivonen
> >> hsivo...@hsivonen.fi 
> >> https://hsivonen.fi/
> >>
> >
> >
> ___
> 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: Dump frame tree in real time

[Jip de Beer]

Hi Botond thanks for replying,

I just checked and calling drawWindow() doesn't output the entire page in the 
display-list dumps. It's as if this operation doesn't trigger the same things a 
regular render operation does.

But your reply got me thinking. If I can force Firefox to always render the 
entire page (instead of the optimized elements currently within the viewport), 
then I have all the information I need in the display-list dumps.

I haven't found a way to do this yet. Can anyone point me to the part of source 
code that chooses which elements to include in the display-list? I'd like to 
override this optimization and include all elements within the document instead.

> Op 16 apr. 2016 om 01:45 heeft Botond Ballo  het volgende 
> geschreven:
> 
>> On Fri, Apr 15, 2016 at 4:32 AM, Jip de Beer  wrote:
>> Thanks for the reply. My problem with display lists is that they only 
>> contain this information about nodes within the viewport. I'm interested in 
>> all nodes that take up space within the document.
>> 
>> I know Firefox can calculate the necessary information for nodes outside of 
>> the viewport because I can take a screenshot of the entire page with 
>> CanvasRenderingContext2D.drawWindow() and it correctly renders the entire 
>> page (also outside of the viewport).
> 
> If it renders the entire page, it must build a display list for the
> entire page. Can you get a display list dump from that operation?
> 
> Cheers,
> Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Element.animate

[smaug]

On 04/19/2016 03:29 AM, bbirt...@mozilla.com wrote:

On Tuesday, 19 April 2016 02:23:54 UTC+9, smaug  wrote:

On 04/18/2016 05:12 AM, Brian Birtles wrote:

In Firefox 48 I intend to turn Element.animate on by default.

We have been developing the Web Animations API behind the 
dom.animations-api.core.enabled preference and have introduced the
dom.animations-api.element-api.enabled preference for the subset of the API 
that we intend to ship at this time.

Chrome have been shipping a very similar subset of the API starting with Chrome 
36[1] and have recently updated their implementation to match
the subset we plan to ship.[2]

WebKit[3] and Edge[4] both list this as "under consideration" although some 
implementation work has begun in WebKit.[5]

This feature was previously discussed in this "intent to implement" thread:
https://groups.google.com/d/topic/mozilla.dev.platform/3EXBgp26rJs/discussion

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1245000 
Link to standard:
https://w3c.github.io/web-animations/#dom-animatable-animate

The subset of the API we intend to ship is described in the bug above, a 
summary of which I have copied to the end of this mail. We do not
intend to ship the 'finished' promise at this time due to concern that this 
should use a cancelable promise.[6]


Does blink ship 'finished' promise?


No. I've just discussed with them and we will also not ship the 'ready' promise 
either, for similar reasons.


Are there good wpt tests where we pass the same tests as other implementers?


Yes. We've contributed a number of tests to wpt and the Chrome team are running 
them against blink and addressing issues that arise. We still have
more tests to contribute though and a few of us are spending a lot of time on 
that at the moment.


// 'Animation' will not be exposed on the global unless Element.animate is 
called

What does this mean? Per spec 'Animation' should be exposed in the global.


Full details are in bug 1245000 from comment 9 onwards 
(https://bugzilla.mozilla.org/show_bug.cgi?id=).

Initially we would like to release Animation as [NoInterfaceObject] because of 
compat concerns that other libraries might be using 'Animation'.
Blink currently ships with [NoInterfaceObject] so we don't know yet if this 
interface name is Web compatible.

(Unlike blink, however, we have implemented the Animation constructor and, 
per-spec, implemented Element.animate() in terms of that constructor.
Hence the slightly odd situation where Animation is not initially on the global 
but might be added if you call Element.animate().)

That doesn't sound like a behavior we should ship. Either make it 
[NoInterfaceObject] or normal interface.
And if it needs to be [NoInterfaceObject], constructor shouldn't be supported.



This is a temporary situation because I don't want to have to back out the 
whole Element.animate feature due to compat issues from the 'Animation'
interface name. After we have shipped Element.animate we can ship the Animation 
constructor behind a different pref.

Why would you need to backout animate() if the interface was 
[NoInterfaceObject] ?


So could we ship constructor + removing [NoInterfaceObject] as a separate step, not when shipping this initial API? And have [NoInterfaceObject] until 
that. If we're worried about web-compatibility, the API spec editors should consider changing the spec to be more likely web-compatible, and better to 
do that before anyone supports the constructor (since I assume it might mean changing the interface name)




-Olli


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

[Firefox Desktop] Issues found: April 11th to 15th

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
team last week, *April 11th - April 15th* (week 15).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1263599 
"View Pocket List" option from the bookmarks menu gone after restart
Firefox
Pocket
YES NOBODY
1263896 
Microphone hovered state icon is incomplete (white line near the 
separator)
Hello (Loop)
Client
NO  NOBODY
1263897 
A/V indicators overlap the other buttons when context is displayed
Hello (Loop)
Client
NO  NOBODY
1264704 
URL Bar loses its focus in about:home during search process
Firefox
Search
NO  NOBODY
1264969 
crash in av_buffer_unref
Core
Graphics
NO  NOBODY


*AURORA CHANNEL*
none

*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1263583 
	[Mac] "Confirm Close" pop-up is shown even though "Show my windows and 
tabs from last time" is in effect

Firefox
Session Restore
NO  NOBODY
1263601 
	crash in mozilla::ipc::FatalError | 
mozilla::dom::PContentParent::FatalError | 
mozilla::dom::PContentParent::Write

Firefox
Developer Tools: Responsive Design Mode
TBD NOBODY
1264193 
Broken Firefox layout when transition from lowdpi to hidpi monitor
Core
Widget: Win32
NO  Jonathan Kew
1264196 
	Text not scaling in Hello and Pocket when firefox is in between lowdpi 
and hidpi screens

Core
Widget: Win32
NO  Jonathan Kew
1264222 
Hello icon misplaced and wrong layout when detaching a second monitor
Core
Layout: Misc Code
TBD NOBODY
1264209 
	crash in ReceivePort::WaitForMessage | 
mozilla::ipc::SharedMemoryBasic::ShareToProcess

Core
WebRTC
NO  NOBODY
1264974 
	The scrollbars from RDM tool are not deselected after releasing the 
click button

Firefox
Developer Tools: Responsive Design Mode
NO  NOBODY
1264982 
The scrollbars from RDM should be visible no matter the background color
Firefox
Developer Tools: Responsive Design Mode
NO  NOBODY
1264987 
The RDM scrollbars are overlapped by the resize button
Firefox
Developer Tools: Responsive Design Mode
NO  NOBODY

*
**ESR CHANNEL*
none


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

Re: Moving XP to ESR?

[Aryeh Gregor]

On Mon, Apr 18, 2016 at 9:02 PM, Chris Peterson  wrote:
> OTOH, if an XP users doesn't mind running an unpatched OS, then they
> probably won't care/know about running an unpatched Chrome browser.

Gmail nags you if you use an outdated Chrome version.  I know someone
who asked me to take a look at their computer because Gmail had a
banner at the top for a few months saying their browser was outdated.
Turns out they were using 32-bit Linux, which Chrome no longer
supports, so I advised them to upgrade to 64-bit at their convenience.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Panos Astithas]

On Fri, Apr 15, 2016 at 5:47 PM, Tantek Çelik 
wrote:

> However, As EKR pointed out, Kyle Huey's
>
> > Why should we be the ones to take the web compat hit on this?
>
> is the fundamentally biggest issue.
>

I realize I'm late to this thread and the discussion has moved the original
proposal towards something more refined and hence more likely to succeed,
but I'd still like to make a case for this tradeoff:

We should be the ones doing this, because we want to be known as the most
secure, most private browser.

This is isn't an easy position to reach or maintain. It's not as clear-cut
as the fastest browser, or the less memory-demanding browser, but it is one
we have identified as holding a competitive advantage for. Security and
privacy impact usability, that is a well-known fact, otherwise we'd all be
using Tor by now. So let's iterate on this or other similar proposals,
let's ship them off by default, let's provide great onboarding experiences,
documentation, whatever it takes, but let's not shy away from even trying.
Because what other path has a better chance to help us get to where we want
to be?

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

Re: Moving XP to ESR?

[Thomas Zimmermann]

Hi

Am 18.04.2016 um 20:02 schrieb Chris Peterson:
> On 4/18/16 6:46 AM, Thomas Zimmermann wrote:
>> Am 18.04.2016 um 15:18 schrieb Kyle Huey:
>>> > 12% of our users are on Windows XP.
>> And XP still runs on ~10% of all desktops. That's an opportunity to
>> convert some of the users to Firefox.
>
> If we want to convert some Chrome XP users, we could run a small
> social media promotion to inform them that Firefox still supports XP.
> Otherwise, how would they know?

True. Maybe get a blog post out, clarifying that Firefox continues to
support XP for the next N years. News sites will spread the word.

>
> OTOH, if an XP users doesn't mind running an unpatched OS, then they
> probably won't care/know about running an unpatched Chrome browser.

There's HW support and requirements of the new OS. And a new OS costs
money, a new browser doesn't.

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

RE: Intent to ship: ParentNode.prepend(), ParentNode.append(), ChildNode.before(), ChildNode.after(), ChildNode.replaceWith()

[Florin Mezei]

Sounds like this may cause WebCompatibility issues? How worried are we about
this? Can we mitigate this through testing?

Regards,
Florin.

-Original Message-
From: dev-platform
[mailto:dev-platform-bounces+florin.mezei=softvisioninc...@lists.mozilla.org
] On Behalf Of smaug
Sent: Monday, April 18, 2016 8:30 PM
To: dev-platform@lists.mozilla.org
Subject: Re: Intent to ship: ParentNode.prepend(), ParentNode.append(),
ChildNode.before(), ChildNode.after(), ChildNode.replaceWith()

OK from me.


Need to still carefully look for any possible regressions.


-Olli


On 04/18/2016 08:11 PM, Jocelyn Liu wrote:
> As of Firefox 48 I intend to ship ParentNode.prepend(), 
> ParentNode.append(), ChildNode.before(), ChildNode.after(), and
> ChildNode.replaceWith() on all platforms.
> These methods would enable web developers to insert a set of nodes or 
> strings into a parent node's children list or before/after a child 
> node, or replace a node with them.
>
> Implementation bug: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=911477
> Link to standard:
> https://dom.spec.whatwg.org/#parentnode
> https://dom.spec.whatwg.org/#childnode
>
> Enabled in WebKit nightly, except for Safari.
> Blink issue: 
> https://bugs.chromium.org/p/chromium/issues/detail?id=255482,
> changesets were backed out, haven't been relanded yet.
>
> Regards,
> Jocelyn
>

___
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: Intent to Ship: HTML5 and tags

[Ting-Yu Lin]

On Tue, Apr 19, 2016 at 11:02 AM, Karl Dubost  wrote:

>
> Le 14 avr. 2016 à 18:24, Ting-Yu Lin  a écrit :
> > On Thu, Apr 14, 2016 at 5:03 PM, Xidorn Quan 
> wrote:
> >> Shouldn't "summary { list-style-type: none; }" be enough?
> > Yes. With Bug 1258657 <
> https://bugzilla.mozilla.org/show_bug.cgi?id=1258657>
> > landed, it's enough to hide the triangle by summary { list-style-type:
> > none; }.
>
>
> So I started some tests this morning
> http://codepen.io/anon/pen/bpKGXg
>
> And list-style-type: none; has 0 effect on Blink/WebKit.
>
> The most common usage of -webkit-details-marker is indeed a variation of:
>summary::-webkit-details-marker { display: none; }
>
> but I found other things too which might create cosmetics Web
> Compatibility issues.
> http://www.otsukare.info/2016/04/19/summary-details
>
>
So far, Blink/Webkit still use "display: block" for the summary, so
"list-style-type" won't have any effect.
Here is the section

in the html spec describe the rendering hint about details and summary.
And here is the chromium bug
 for
implementing the triangle as a list item.

The current portable way to hide the triangle is to specify both
  summary::-webkit-details-marker { display: none; }
and
  summary { list-style-type: none; }

As I described in bug 1258657
, some website
like Edge FAQ
,
which happens to write
  summary::-webkit-details-marker { display: none; }
  summary { display:block; }
and offer their customized triangle by summary::after or summary::before
will luckily avoid the cosmetics issue.

Ting-Yu



>
> --
> Karl Dubost, Mozilla
> http://www.la-grange.net/karl/moz
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform