How to use resizer in that the size is zero? That means the resize didn't see but works

[Yonggang Luo]

Because our UI are customized by ourself, So we need the width of resize to be 
'zero', (Zero doesn't mean truely zero, just we can not see it).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to setting border-radius for window without the default style.

[Yonggang Luo]

Thanks for your response, now I know how to deal with this problem.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to setting border-radius for window without the default style.

[Boris Zbarsky]

On 7/21/14, 9:50 PM, Yonggang Luo wrote:

I am not so sure I understand correctly, is that the answer is there is no 
solution, the only accept way is using a transparent background?


If you want the background clipped to the rounded border, and the 
rounded border to be on the root, then you can't do that.


-Boris

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

Re: How to setting border-radius for window without the default style.

[Yonggang Luo]

I am not so sure I understand correctly, is that the answer is there is no 
solution, the only accept way is using a transparent background?
在 2014年7月22日星期二UTC+8上午12时07分24秒，Boris Zbarsky写道：
> On 7/21/14, 9:35 AM, Markus Stange wrote:
> 
> > Oops, I was forgetting about borders. border-radius works for getting
> 
> > rounded borders on root elements, but it does not work for clipping
> 
> > backgrounds to a rounded rect.
> 
> 
> 
> Right, because of background propagation to the viewport.  The spec 
> 
> calls this out explicitly: the background-clip property doesn't apply to 
> 
> the root, so there is no clipping to the border there.
> 
> 
> 
> -Boris

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

MemShrink Meeting - Tuesday, 22 July 2014 at 4:00pm PDT

[Jet Villegas]

The next MemShrink meeting is brought to you by the slimmer Firefox OS 2.0 
Homescreen:
https://bugzilla.mozilla.org/show_bug.cgi?id=1029902

The wiki page for this meeting is at:
   https://wiki.mozilla.org/Performance/MemShrink

Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.

Meeting details:

* Tue, 22 July, 4:00 PM PDT
* http://arewemeetingyet.com/Los%20Angeles/2014-07-22/16:00/MemShrink%20Meeting
* Vidyo: Memshrink
* Dial-in Info:
   - In office or soft phone: extension 92
   - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
   - Toll-free: 800-707-2533 then password 369
   - Conference num 98802
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Studying Lossy Image Compression Efficiency, July 2014

[Bryan Stillwell]

One option that I haven't seen compared is the combination of JPEG w/ packJPG 
(http://packjpg.encode.ru/?page_id=17).  packJPG can further compress JPEG 
images another 20%+ and still reproduce the original bit-for-bit.

More details on how this is done can be found here:

http://mattmahoney.net/dc/dce.html#Section_616

To me it seems that JPEG+packJPG could be competitive or exceed HEVC-MSP on 
bits/pixel.

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

Re: Intent to Implement: New Push API

[Ehsan Akhgari]

On 2014-07-21, 4:25 PM, nmara...@mozilla.com wrote:

On Monday, July 21, 2014 11:00:13 AM UTC-7, Ehsan Akhgari wrote:

On 2014-07-21, 12:22 PM, Tyler Smith wrote:


Summary: New Push API to replace the current specification for SimplePush.



   Purposes include



1) Switching to Promise, which was sorely needed.



2) Establishing that the data field of messages is required.



3) Establishing that all background communication happens over HTTPS



4) Agreeing that the DOM API should not have to care what Push backend the



device is using



5) Playing nicer with the interface exposure model (earlier we just



wouldn't show navigator.push to apps without permission)




Can you please clarify what you mean here?  How are you looking to

expose the new property?


Ah, this is my fault in explaining things a bit wrong to Tyler. It'll be 
exposed the way we expose all the other APIs, nothing special. It will be 
hidden behind dom.push.enabled, although I'd like it to be enabled by default 
on non Release builds. The new spec is exposed as 
navigator.pushRegistrationManager so it does not conflict with navigator.push.


That sounds good.


Hmm, the spec here  talks

about navigator.push.  Is that something that is going to change in the

spec?


Sadly the spec hasn't been updated in several months. Eduardo, one of the 
editor's intends to get on it in August after he is back from vacation.


Understood.  No concerns form me there as long as we keep up with the 
developments on the spec side as our implementation makes progress.


Cheers,
Ehsan

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

Re: Intent to Implement: New Push API

[nmarathe]

On Monday, July 21, 2014 11:00:13 AM UTC-7, Ehsan Akhgari wrote:
> On 2014-07-21, 12:22 PM, Tyler Smith wrote:
> 
> > Summary: New Push API to replace the current specification for SimplePush.
> 
> >   Purposes include
> 
> > 1) Switching to Promise, which was sorely needed.
> 
> > 2) Establishing that the data field of messages is required.
> 
> > 3) Establishing that all background communication happens over HTTPS
> 
> > 4) Agreeing that the DOM API should not have to care what Push backend the
> 
> > device is using
> 
> > 5) Playing nicer with the interface exposure model (earlier we just
> 
> > wouldn't show navigator.push to apps without permission)
> 
> 
> 
> Can you please clarify what you mean here?  How are you looking to 
> 
> expose the new property?

Ah, this is my fault in explaining things a bit wrong to Tyler. It'll be 
exposed the way we expose all the other APIs, nothing special. It will be 
hidden behind dom.push.enabled, although I'd like it to be enabled by default 
on non Release builds. The new spec is exposed as 
navigator.pushRegistrationManager so it does not conflict with navigator.push.


> 
> Hmm, the spec here  talks 
> 
> about navigator.push.  Is that something that is going to change in the 
> 
> spec?

Sadly the spec hasn't been updated in several months. Eduardo, one of the 
editor's intends to get on it in August after he is back from vacation.

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

Re: Intent to implement: navigator.deviceStorage

[Ehsan Akhgari]

Yes, indeed.  Below, I meant to agree with adding a new EventTarget 
where these events can be targeted to.  :-)


Cheers,
Ehsan

On 2014-07-21, 12:05 PM, Marco Chen wrote:

Yes, I agree with you for virtual device storage API.

But before discussing the detail of virutal device storage api,
the first step here is to figure out where should new event handler be
added?

Since there is not only new event handler been added but also a set of
APIs potentially,
I support to Dave' suggestion.

*寄件者: *"Ehsan Akhgari" 
*收件者: *mc...@mozilla.com, dev-platform@lists.mozilla.org
*寄件備份: *2014 7 月 21 星期一 下午 11:32:33
*主旨: *Re: Intent to implement: navigator.deviceStorage

On 2014-07-20, 10:43 PM, mc...@mozilla.com wrote:
 >> Perhaps adding an
 >> EventListener on Window would be enough, so that we can keep the
same API?
 >
 > As Dave said, we might still need to propose a set of WebAPI for
Virutal Device Storage (Then we can have apps like dropboxstorage app,
googledriverstorage app and sambaStorage app). If we can add
navigator.deviceStorage then these old and new proposed APIs can be put
together. (not sure this is a principle of designing Web API or we can
split functions/events to different places).

That sounds good, but of course we need a more concrete proposal for the
virtual device storage API.

Cheers,
Ehsan




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

Re: Intent to Implement: New Push API

[Ehsan Akhgari]

On 2014-07-21, 12:22 PM, Tyler Smith wrote:

Summary: New Push API to replace the current specification for SimplePush.
  Purposes include
1) Switching to Promise, which was sorely needed.
2) Establishing that the data field of messages is required.
3) Establishing that all background communication happens over HTTPS
4) Agreeing that the DOM API should not have to care what Push backend the
device is using
5) Playing nicer with the interface exposure model (earlier we just
wouldn't show navigator.push to apps without permission)


Can you please clarify what you mean here?  How are you looking to 
expose the new property?


Also, I'm not sure if you're just trying to implement this hidden behind 
a preference or if you are thinking about shipping it by default.



6) Supporting a feature set that at least one other implementer has agreed
upon, rather than what we just cooked up to support on fxos


I assume that is Blink?  (That's great news BTW!)


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

Link to Spec (informal disussion):
https://docs.google.com/document/d/1EeUDLsMLc1dtAk9uHVwnP1N8AFnH7vVVgec_h7BWlI4/edit?pli=1#

Distilled Spec:
Promise register() => registration, or promise rejected
if fails
Promise unregister() => true if successful, else false
Promise hasPermission() => “need-ask”/”granted”/”denied” (never
fails)
Promise isRegistered() => true, false, or promise rejected if
unknown

Platform Coverage: FXOS, Desktop FF, and Firefox Mobile

Preference: dom.push.enabled

We don't intend to break backwards compatibility with the old push system
in the immediate future.  The navigator property for the new push API is
pushRegistrationManager, so the thinking right now is that for a few
releases the two will be offered side by side as completely distinct
services, but with the intent to remove the old push system at some point.


Hmm, the spec here  talks 
about navigator.push.  Is that something that is going to change in the 
spec?


Cheers,
Ehsan

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

Re: Intent to Implement: New Push API

[Martin Thomson]

The latest version of the API spec is here: 
https://w3c.github.io/push-api/index.html

That’s potentially in flux.  What are your plans should something major change?


On 2014-07-21, at 09:22, Tyler Smith  wrote:

> Summary: New Push API to replace the current specification for SimplePush.
> Purposes include
> 1) Switching to Promise, which was sorely needed.
> 2) Establishing that the data field of messages is required.
> 3) Establishing that all background communication happens over HTTPS
> 4) Agreeing that the DOM API should not have to care what Push backend the
> device is using
> 5) Playing nicer with the interface exposure model (earlier we just
> wouldn't show navigator.push to apps without permission)
> 6) Supporting a feature set that at least one other implementer has agreed
> upon, rather than what we just cooked up to support on fxos
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1038811
> 
> Link to Spec (informal disussion):
> https://docs.google.com/document/d/1EeUDLsMLc1dtAk9uHVwnP1N8AFnH7vVVgec_h7BWlI4/edit?pli=1#
> 
> Distilled Spec:
> Promise register() => registration, or promise rejected
> if fails
> Promise unregister() => true if successful, else false
> Promise hasPermission() => “need-ask”/”granted”/”denied” (never
> fails)
> Promise isRegistered() => true, false, or promise rejected if
> unknown
> 
> Platform Coverage: FXOS, Desktop FF, and Firefox Mobile
> 
> Preference: dom.push.enabled
> 
> We don't intend to break backwards compatibility with the old push system
> in the immediate future.  The navigator property for the new push API is
> pushRegistrationManager, so the thinking right now is that for a few
> releases the two will be offered side by side as completely distinct
> services, but with the intent to remove the old push system at some point.
> ___
> 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

Form autofill + pushState

[cowwoc]

Hi,

Does Firefox autofill Forms that were submitted using AJAX + pushState? 
Chrome plans to add support: 
https://code.google.com/p/chromium/issues/detail?id=43219#c39


and I want to know where Firefox stands on this issue. Do you plan to 
add such support? Have you already?


In your opinion, what is the best way to submit forms using AJAX without 
losing autofill support?


Thank you,
Gili
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux Off-main-thread compositing (OMTC) enabled

[Ed Morley]

The OMTC changes are not on mozilla-central, the landing and subsequent 
backout are still on mozilla-inbound.


The Nightly crashes you are seeing are bug 1041492 which is fixed in 
the freshly respun nightly.


Ed

On 21/07/2014 17:43:40, Paul Rouget wrote:

Also - now nightly crashes at startup. It happens to me, and to a couple
of people on twitter.

How do I disable OMTC from the command line to see if it's OMTC related?

Ed Morley wrote:

On 21/07/2014 16:53:37, Christopher Lord wrote:

Earlier today, I pushed the patch that enables OMTC on Linux[1][2], meaning we 
will now have OMTC enabled on all platforms. Linux is slightly different to 
other platforms, as we currently have hardware-accelerated layers disabled. 
This means it uses the BasicCompositor, which before this point, is not hugely 
well-tested. Please keep an eye out for any visual regressions, and we'll do 
our best to stay on top of them.


Unfortunately this has had to be backed out for reftest timeouts on
our 32bit Ubuntu EC2 instances:
https://tbpl.mozilla.org/php/getParsedLog.php?id=44274684&tree=Mozilla-Inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/3b5e46a568f1
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

-- Paul

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

Re: Linux Off-main-thread compositing (OMTC) enabled

[Paul Rouget]

Also - now nightly crashes at startup. It happens to me, and to a couple
of people on twitter.

How do I disable OMTC from the command line to see if it's OMTC related?

Ed Morley wrote:
> On 21/07/2014 16:53:37, Christopher Lord wrote:
> >Earlier today, I pushed the patch that enables OMTC on Linux[1][2], meaning 
> >we will now have OMTC enabled on all platforms. Linux is slightly different 
> >to other platforms, as we currently have hardware-accelerated layers 
> >disabled. This means it uses the BasicCompositor, which before this point, 
> >is not hugely well-tested. Please keep an eye out for any visual 
> >regressions, and we'll do our best to stay on top of them.
> 
> Unfortunately this has had to be backed out for reftest timeouts on
> our 32bit Ubuntu EC2 instances:
> https://tbpl.mozilla.org/php/getParsedLog.php?id=44274684&tree=Mozilla-Inbound
> https://hg.mozilla.org/integration/mozilla-inbound/rev/3b5e46a568f1
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
-- Paul
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux Off-main-thread compositing (OMTC) enabled

[Ed Morley]

On 21/07/2014 16:53:37, Christopher Lord wrote:

Earlier today, I pushed the patch that enables OMTC on Linux[1][2], meaning we 
will now have OMTC enabled on all platforms. Linux is slightly different to 
other platforms, as we currently have hardware-accelerated layers disabled. 
This means it uses the BasicCompositor, which before this point, is not hugely 
well-tested. Please keep an eye out for any visual regressions, and we'll do 
our best to stay on top of them.


Unfortunately this has had to be backed out for reftest timeouts on our 
32bit Ubuntu EC2 instances:

https://tbpl.mozilla.org/php/getParsedLog.php?id=44274684&tree=Mozilla-Inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/3b5e46a568f1
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Implement: New Push API

[Tyler Smith]

Summary: New Push API to replace the current specification for SimplePush.
 Purposes include
1) Switching to Promise, which was sorely needed.
2) Establishing that the data field of messages is required.
3) Establishing that all background communication happens over HTTPS
4) Agreeing that the DOM API should not have to care what Push backend the
device is using
5) Playing nicer with the interface exposure model (earlier we just
wouldn't show navigator.push to apps without permission)
6) Supporting a feature set that at least one other implementer has agreed
upon, rather than what we just cooked up to support on fxos

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

Link to Spec (informal disussion):
https://docs.google.com/document/d/1EeUDLsMLc1dtAk9uHVwnP1N8AFnH7vVVgec_h7BWlI4/edit?pli=1#

Distilled Spec:
Promise register() => registration, or promise rejected
if fails
Promise unregister() => true if successful, else false
Promise hasPermission() => “need-ask”/”granted”/”denied” (never
fails)
Promise isRegistered() => true, false, or promise rejected if
unknown

Platform Coverage: FXOS, Desktop FF, and Firefox Mobile

Preference: dom.push.enabled

We don't intend to break backwards compatibility with the old push system
in the immediate future.  The navigator property for the new push API is
pushRegistrationManager, so the thinking right now is that for a few
releases the two will be offered side by side as completely distinct
services, but with the intent to remove the old push system at some point.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to setting border-radius for window without the default style.

[Boris Zbarsky]

On 7/21/14, 9:35 AM, Markus Stange wrote:

Oops, I was forgetting about borders. border-radius works for getting
rounded borders on root elements, but it does not work for clipping
backgrounds to a rounded rect.


Right, because of background propagation to the viewport.  The spec 
calls this out explicitly: the background-clip property doesn't apply to 
the root, so there is no clipping to the border there.


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

Re: Intent to implement: navigator.deviceStorage

[Marco Chen]

Yes, I agree with you for virtual device storage API. 

But before discussing the detail of virutal device storage api, 
the first step here is to figure out where should new event handler be added? 

Since there is not only new event handler been added but also a set of APIs 
potentially, 
I support to Dave' suggestion. 
- 原始郵件 -

寄件者: "Ehsan Akhgari"  
收件者: mc...@mozilla.com, dev-platform@lists.mozilla.org 
寄件備份: 2014 7 月 21 星期一 下午 11:32:33 
主旨: Re: Intent to implement: navigator.deviceStorage 

On 2014-07-20, 10:43 PM, mc...@mozilla.com wrote: 
>> Perhaps adding an 
>> EventListener on Window would be enough, so that we can keep the same API? 
> 
> As Dave said, we might still need to propose a set of WebAPI for Virutal 
> Device Storage (Then we can have apps like dropboxstorage app, 
> googledriverstorage app and sambaStorage app). If we can add 
> navigator.deviceStorage then these old and new proposed APIs can be put 
> together. (not sure this is a principle of designing Web API or we can split 
> functions/events to different places). 

That sounds good, but of course we need a more concrete proposal for the 
virtual device storage API. 

Cheers, 
Ehsan 


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

Linux Off-main-thread compositing (OMTC) enabled

[Christopher Lord]

Hi all,

Earlier today, I pushed the patch that enables OMTC on Linux[1][2], meaning we 
will now have OMTC enabled on all platforms. Linux is slightly different to 
other platforms, as we currently have hardware-accelerated layers disabled. 
This means it uses the BasicCompositor, which before this point, is not hugely 
well-tested. Please keep an eye out for any visual regressions, and we'll do 
our best to stay on top of them.

There is an expected, marked performance regression in some tests when enabling 
this feature. This is mainly due to measurements not taking into account the 
asynchronicity of X (and the omtc path having a couple more XSync's) - Some of 
these results are false, and so the new numbers don't actually represent as 
much of a regression as you would initially think. It's worth noting that Linux 
numbers are now more in line with our other platforms.

Some of the performance regression is real, due to unoptimised display paths in 
BasicCompositor[3][4]. These will eventually be resolved, as I believe we'll 
require this path on other platforms.

There are also performance wins; Scrolling performance is improved and OMTC 
allows us to have asynchronous video playback, which is also a huge 
improvement. Canvas performance also improves (for some unknown reason...) The 
gfx team has discussed this at length and we believe the performance trade-off 
is very much worth it, especially considering the things OMTC allows us to 
enable/do in the future.

If you have issues, me, Bas Scouten and Nicolas Silva should be able to address 
them.

Brace yourselves!

--Chris

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=994541
[2] When it gets merged: https://hg.mozilla.org/mozilla-central/rev/ea2341b06e6f
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=994554
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=994556
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: navigator.deviceStorage

[Ehsan Akhgari]

On 2014-07-20, 10:43 PM, mc...@mozilla.com wrote:

Perhaps adding an
EventListener on Window would be enough, so that we can keep the same API?


As Dave said, we might still need to propose a set of WebAPI for Virutal Device 
Storage (Then we can have apps like dropboxstorage app, googledriverstorage app 
and sambaStorage app). If we can add navigator.deviceStorage then these old and 
new proposed APIs can be put together. (not sure this is a principle of 
designing Web API or we can split functions/events to different places).


That sounds good, but of course we need a more concrete proposal for the 
virtual device storage API.


Cheers,
Ehsan

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

Re: Intent to implement: AbortablePromise and AbortableProgressPromise

[Ehsan Akhgari]

On Sat, Jul 19, 2014 at 5:49 AM, Jonas Sicking  wrote:

> Something like this is likely to get standardized eventually. But I think
> it will take longer than we are willing to wait.
>
> In the meantime we should only expose this API to pages that have
> permission to use DeviceStorage, which is where we are planning to use this.
>
> This way these classes effectively become part of DeviceStorage and can
> evolve with that API.
>
OK, that sounds good to me.


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

Re: Studying Lossy Image Compression Efficiency, July 2014

[Gabriele Svelto]

On 19/07/2014 22:40, Ralph Giles wrote:
> Probably not for Firefox OS, if you mean mozjpeg. Not necessarily
> because it uses hardware, but because mozjpeg is about spending more cpu
> power to compress images. It's more something you'd use server-side or
> in creating apps. The phone uses libjpeg-turbo for image decoding, which
> is fast, just not as good an compression.

It might be useful in Firefox OS development: we routinely re-compress
PNG assets in FxOS but we never tried re-compressing our JPEG assets
(which are mostly wallpapers IIRC).

 Gabriele



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

Re: How to setting border-radius for window without the default style.

[Markus Stange]

On 21.07.14 14:59, Boris Zbarsky wrote:

On 7/21/14, 8:36 AM, Markus Stange wrote:

On 21.07.14 13:33, Yonggang Luo wrote:

I am trying to remove the default style for tag 
but failed to setting the radius.


Setting a border radius on the root element is not supported.


In XUL, right?  Works fine in HTML.


Oops, I was forgetting about borders. border-radius works for getting 
rounded borders on root elements, but it does not work for clipping 
backgrounds to a rounded rect. In that sense it seems to work 
identically in XUL and in HTML.


Here's what I tested with:

data:text/html,


open('data:application/vnd.mozilla.xul+xml,xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"; 
width="400" height="200" style="background:red;border:1px solid 
black;border-radius:20px"/>', '', 'chrome')


-Markus

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

Re: How to setting border-radius for window without the default style.

[Boris Zbarsky]

On 7/21/14, 8:36 AM, Markus Stange wrote:

On 21.07.14 13:33, Yonggang Luo wrote:

I am trying to remove the default style for tag 
but failed to setting the radius.


Setting a border radius on the root element is not supported.


In XUL, right?  Works fine in HTML.

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

Re: How to setting border-radius for window without the default style.

[Markus Stange]

On 21.07.14 13:33, Yonggang Luo wrote:

I am trying to remove the default style for tag 
but failed to setting the radius.


Setting a border radius on the root element is not supported. You'll 
need to make the window element transparent and add a wrapper element 
(like ) that you set the border radius on.


-Markus

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

How to setting border-radius for window without the default style.

[Yonggang Luo]

I am trying to remove the default style for tag 
but failed to setting the radius.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform