How to setting border-radius for window without the default style.
I am trying to remove the default style for tag window / but failed to setting the radius. ___ 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.
On 21.07.14 13:33, Yonggang Luo wrote: I am trying to remove the default style for tag window / 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 vbox) that you set the border radius on. -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.
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 window / 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.
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 window /
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,html style=background:red;border:1px solid
black;border-radius:20px
open('data:application/vnd.mozilla.xul+xml,window
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: Studying Lossy Image Compression Efficiency, July 2014
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: Intent to implement: AbortablePromise and AbortableProgressPromise
On Sat, Jul 19, 2014 at 5:49 AM, Jonas Sicking jo...@sicking.cc 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: 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
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
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 ehsan.akhg...@gmail.com 收件者: 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: How to setting border-radius for window without the default style.
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
Intent to Implement: New Push API
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: PromisePushRegistration register() = registration, or promise rejected if fails Promiseboolean unregister() = true if successful, else false PromiseDOMString hasPermission() = “need-ask”/”granted”/”denied” (never fails) Promiseboolean 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: Linux Off-main-thread compositing (OMTC) enabled
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=44274684tree=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
Re: Linux Off-main-thread compositing (OMTC) enabled
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=44274684tree=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
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=44274684tree=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
Form autofill + pushState
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: Intent to Implement: New Push API
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 tylsm...@gmail.com 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: PromisePushRegistration register() = registration, or promise rejected if fails Promiseboolean unregister() = true if successful, else false PromiseDOMString hasPermission() = “need-ask”/”granted”/”denied” (never fails) Promiseboolean 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
Re: Intent to Implement: New Push API
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: PromisePushRegistration register() = registration, or promise rejected if fails Promiseboolean unregister() = true if successful, else false PromiseDOMString hasPermission() = “need-ask”/”granted”/”denied” (never fails) Promiseboolean 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 https://w3c.github.io/push-api/index.html 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: navigator.deviceStorage
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 ehsan.akhg...@gmail.com *收件者: *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
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 https://w3c.github.io/push-api/index.html 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: New Push API
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 https://w3c.github.io/push-api/index.html 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: Studying Lossy Image Compression Efficiency, July 2014
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
MemShrink Meeting - Tuesday, 22 July 2014 at 4:00pm PDT
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: How to setting border-radius for window without the default style.
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
Re: How to setting border-radius for window without the default style.
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
How to use resizer in window that the size is zero? That means the resize didn't see but works
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.
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
