Intent to implement: AbortablePromise and AbortableProgressPromise
Hi all,/ Summary/: These are subclasses of Promise. Allow promise to be canceled or send progress notification. They are planned to be used by some APIs, such as XMLHttpRequest, FileAPI, Filesystem API, the openDirectoryPicker of input... /Bug/: https://bugzilla.mozilla.org/show_bug.cgi?id=1035060 and https://bugzilla.mozilla.org/show_bug.cgi?id=1038557 /Link to standard/: https://groups.google.com/forum/#!topic/mozilla.dev.webapi/N1FjiEqCflI /Platform coverage/: Firefox OS /Estimated or target release/: ? /Preference behind which this will be implemented/: dom.abortablepromise.enabled for AbortablePromise, while AbortableProgressPromise will not be exposed to web and is available on having any devicestorage permission. --Yuan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
The warning about the Java Deployment Toolkit should be removed.
The issue was resolved by Oracle some time ago. Continued display of this message is disconcerting to some people and unwarranted. It was a good thing when the vulnerability was first discovered but it's now a bad thing. Could some dev pick this up and clear that message? Thanks ___ 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 Tuesday, July 15, 2014 3:34:35 PM UTC+1, Josh Aas wrote: This is the discussion thread for Mozilla's July 2014 Lossy Compressed Image Formats Study and the Mozilla Research blog post entitled Mozilla Advances JPEG Encoding with mozjpeg 2.0. Josh, I work for CloudFlare on many things but recently on image compression. We have a product called Polish that recompresses images for our customers automatically. As we are in the process of rolling out a new version I looked at mozjpeg 2.0. I selected 10,000 random JPEGs that we were caching for customers and ran them through mozjpeg 2.0 via jpegtran. Some interesting facts: 1. 691 files were not compressed further. This compares with 3,471 that libjpeg-turbo did not compress further. 2. Of the compression files the average compression was about 3%. 3. Run time was about 1.7x the libjpeg-turbo time. 4. I've put together a small chart showing the distribution of compression that we saw. It's here: https://twitter.com/jgrahamc/status/490114514667327488/photo/1 We will continue to work with mozjpeg 2.0 experimentally with the hope that run time can be brought closer to what we had before as the compression looks good. John. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: The warning about the Java Deployment Toolkit should be removed.
Which warning are you referring to exactly? Do you have a screenshot? Gavin On Fri, Jul 18, 2014 at 5:48 AM, JW Clements m...@jwcca.com wrote: The issue was resolved by Oracle some time ago. Continued display of this message is disconcerting to some people and unwarranted. It was a good thing when the vulnerability was first discovered but it's now a bad thing. Could some dev pick this up and clear that message? Thanks ___ 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: fine-grained filtering of bugmail
I added the following filters to my account: Any Any Iteration Any Exclude Any Any Points Any Exclude My expected behavior is: - if someone modifies the Points field - bugmail filtered - if someone modifies the Points field and the Iteration field - bugmail filtered - if someone modifies the Points field and adds a comment - bugmail allowed Am I understanding how these work correctly? Gavin On Sun, Jul 13, 2014 at 11:13 PM, Byron Jones g...@mozilla.com wrote: are you tired of receiving notifications from bugzilla that you simply don't care about? you can now tell bugzilla to stop clogging up your inbox with those pesky emails via bugmail filtering. are you only interested in seeing new bugs and bug status changes in some components you are watching? set up a filter! or perhaps you only want to be informed about qa related changes on bug where you are the assignee? set up a filter! see http://globau.wordpress.com/2014/07/10/using-bugmail-filtering-to-exclude-notifications-you-dont-want/ for more details. -- byron jones - :glob - bugzilla.mozilla.org team - ___ 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: The warning about the Java Deployment Toolkit should be removed.
From an off-thread reply this is: https://addons.mozilla.org/en-US/firefox/blocked/p428 https://bugzilla.mozilla.org/show_bug.cgi?id=636633 We blocked all versions last year, since it was easier than trying to block only the vulnerable versions (https://bugzilla.mozilla.org/show_bug.cgi?id=636633#c8). There have since been versions released that apparently have no known vulnerabilities. It's not clear why some people in the bug are so up in arms about the overly broad block - is the plugin actually useful in ways we weren't aware of, or do people just not like seeing the blocked message unnecessarily? With click to play on by default we could probably remove the broad block, but we'd want to still block the known-vulnerable versions, which would require coming up with a regexp that matches only the right versions. Gavin On Fri, Jul 18, 2014 at 11:17 AM, Gavin Sharp ga...@gavinsharp.com wrote: Which warning are you referring to exactly? Do you have a screenshot? Gavin On Fri, Jul 18, 2014 at 5:48 AM, JW Clements m...@jwcca.com wrote: The issue was resolved by Oracle some time ago. Continued display of this message is disconcerting to some people and unwarranted. It was a good thing when the vulnerability was first discovered but it's now a bad thing. Could some dev pick this up and clear that message? Thanks ___ 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: AbortablePromise and AbortableProgressPromise
Hi Yuan, Do we have feedback from other browser vendors on these APIs? Is there agreement on them? Cheers, Ehsan On 2014-07-18, 5:29 AM, Yuan Xulei(袁徐磊) wrote: Hi all,/ Summary/: These are subclasses of Promise. Allow promise to be canceled or send progress notification. They are planned to be used by some APIs, such as XMLHttpRequest, FileAPI, Filesystem API, the openDirectoryPicker of input... /Bug/: https://bugzilla.mozilla.org/show_bug.cgi?id=1035060 and https://bugzilla.mozilla.org/show_bug.cgi?id=1038557 /Link to standard/: https://groups.google.com/forum/#!topic/mozilla.dev.webapi/N1FjiEqCflI /Platform coverage/: Firefox OS /Estimated or target release/: ? /Preference behind which this will be implemented/: dom.abortablepromise.enabled for AbortablePromise, while AbortableProgressPromise will not be exposed to web and is available on having any devicestorage permission. --Yuan ___ 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: navigator.deviceStorage
On Wed, Jul 16, 2014 at 9:08 PM, Dave Hylands dhyla...@mozilla.com wrote: Currently, we have navigator.getDeviceStorage and navigator.getDeviceStorages We're looking to expand device storage to add support for more virtual storage areas, like DropBox, or GoogleDrive, etc. See bug 1035053 I was going to propose that we add navigator.deviceStorage (or possibly navigator.mozDeviceStorage) and have at least the following methods: deviceStorage.addObserver deviceStorage.removeObserver addObserver/removeObserver are Gecko-isms that don't really have a counterpart in Web APIs. Why not use an EventListener? deviceStorage.getAll deviceStorage.getDefault We need some new notifications, one to report when the default volume has changed (on B2G it is controlled by a setting which then gets reflected into a preference), one to report when a new storage area (like DropBox) is added, and one to report when it goes away. Presumably we'd also need additional APIs to actually add/remove storage areas. deviceStorage.getAll would return exactly what navigator.getDeviceStorages returns today, and deviceStorage.getDefault would return exactly what navigator.getDevicetorages returns today. I think that we probably need to leave getDeviceStorage and getDeviceStorages both around for the time being in order to maintain backwards capability. So getAll/getDefault would be exactly like getDeviceStorage()/getDeviceStorages? If so, I'm not really sure what we gain from this renaming... Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: navigator.deviceStorage
- Original Message - From: Ehsan Akhgari ehsan.akhg...@gmail.com To: Dave Hylands dhyla...@mozilla.com Cc: dev-platform dev-platform@lists.mozilla.org Sent: Friday, July 18, 2014 2:14:50 PM Subject: Re: Intent to implement: navigator.deviceStorage On Wed, Jul 16, 2014 at 9:08 PM, Dave Hylands dhyla...@mozilla.com wrote: Currently, we have navigator.getDeviceStorage and navigator.getDeviceStorages We're looking to expand device storage to add support for more virtual storage areas, like DropBox, or GoogleDrive, etc. See bug 1035053 I was going to propose that we add navigator.deviceStorage (or possibly navigator.mozDeviceStorage) and have at least the following methods: deviceStorage.addObserver deviceStorage.removeObserver addObserver/removeObserver are Gecko-isms that don't really have a counterpart in Web APIs. Why not use an EventListener? No reason, other than I'm not familiar with EventListener. What is an EventListener and how would you use it? Maybe just point me at an example? deviceStorage.getAll deviceStorage.getDefault We need some new notifications, one to report when the default volume has changed (on B2G it is controlled by a setting which then gets reflected into a preference), one to report when a new storage area (like DropBox) is added, and one to report when it goes away. Presumably we'd also need additional APIs to actually add/remove storage areas. deviceStorage.getAll would return exactly what navigator.getDeviceStorages returns today, and deviceStorage.getDefault would return exactly what navigator.getDevicetorages returns today. I think that we probably need to leave getDeviceStorage and getDeviceStorages both around for the time being in order to maintain backwards capability. So getAll/getDefault would be exactly like getDeviceStorage()/getDeviceStorages? If so, I'm not really sure what we gain from this renaming... We need someway to add listeners for the default storage area changing and for new storage areas coming and going, and possibly even for an API to add/remove storage areas. So it felt to me that having a new entity called deviceStorage with all of the device storage functionality contained within it seemed more natural to me than adding several more free functions into the namespace. I don't really have an opinion one way or the other. I'd just like to move things along in a decent direction, but I just don't know what that means. Dave Hylands ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: navigator.deviceStorage
On 18/07/14 23:28, Dave Hylands wrote: addObserver/removeObserver are Gecko-isms that don't really have a counterpart in Web APIs. Why not use an EventListener? No reason, other than I'm not familiar with EventListener. What is an EventListener and how would you use it? Maybe just point me at an example? I believe that Ehsan is referring to https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Event_handlers -- David Rajchenbach-Teller, PhD Performance Team, Mozilla 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: navigator.deviceStorage
On 2014-07-18 2:28 PM, Dave Hylands wrote:
No reason, other than I'm not familiar with EventListener. What is an
EventListener and how would you use it? Maybe just point me at an example?
deviceStorage.addEventListener('newarea', function(event) {
// Handle new area being available.
});
It's a generic pattern implemented by many objects, and multiple
listeners can be registered. You define the event names and the rules
for triggering them in the spec, then code can easily subscribe to the
changes it wants to observe.
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Registration-interfaces
https://developer.mozilla.org/en-US/docs/Web/API/EventListener
-r
___
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-18, 5:28 PM, Dave Hylands wrote: *From: *Ehsan Akhgari ehsan.akhg...@gmail.com *To: *Dave Hylands dhyla...@mozilla.com *Cc: *dev-platform dev-platform@lists.mozilla.org *Sent: *Friday, July 18, 2014 2:14:50 PM *Subject: *Re: Intent to implement: navigator.deviceStorage On Wed, Jul 16, 2014 at 9:08 PM, Dave Hylands dhyla...@mozilla.com mailto:dhyla...@mozilla.com wrote: Currently, we have navigator.getDeviceStorage and navigator.getDeviceStorages We're looking to expand device storage to add support for more virtual storage areas, like DropBox, or GoogleDrive, etc. See bug 1035053 I was going to propose that we add navigator.deviceStorage (or possibly navigator.mozDeviceStorage) and have at least the following methods: deviceStorage.addObserver deviceStorage.removeObserver addObserver/removeObserver are Gecko-isms that don't really have a counterpart in Web APIs. Why not use an EventListener? No reason, other than I'm not familiar with EventListener. What is an EventListener and how would you use it? Maybe just point me at an example? What David and Ralph said! You can grep dom/webidl for EventListener to find many examples of this. Also, see EventTarget. deviceStorage.getAll deviceStorage.getDefault We need some new notifications, one to report when the default volume has changed (on B2G it is controlled by a setting which then gets reflected into a preference), one to report when a new storage area (like DropBox) is added, and one to report when it goes away. Presumably we'd also need additional APIs to actually add/remove storage areas. deviceStorage.getAll would return exactly what navigator.getDeviceStorages returns today, and deviceStorage.getDefault would return exactly what navigator.getDevicetorages returns today. I think that we probably need to leave getDeviceStorage and getDeviceStorages both around for the time being in order to maintain backwards capability. So getAll/getDefault would be exactly like getDeviceStorage()/getDeviceStorages? If so, I'm not really sure what we gain from this renaming... We need someway to add listeners for the default storage area changing and for new storage areas coming and going, and possibly even for an API to add/remove storage areas. So it felt to me that having a new entity called deviceStorage with all of the device storage functionality contained within it seemed more natural to me than adding several more free functions into the namespace. I don't really have an opinion one way or the other. I'd just like to move things along in a decent direction, but I just don't know what that means. Ah I see. I think that your intent is pure, but changing the API like this will break existing apps that rely on it. Perhaps adding an EventListener on Window would be enough, so that we can keep the same API? (Also, please see Marco's email about this to dev-webapi. It would be nice if we could coordinate our efforts here.) 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 Fri, Jul 18, 2014 at 2:49 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2014-07-18, 5:28 PM, Dave Hylands wrote: *From: *Ehsan Akhgari ehsan.akhg...@gmail.com *To: *Dave Hylands dhyla...@mozilla.com *Cc: *dev-platform dev-platform@lists.mozilla.org *Sent: *Friday, July 18, 2014 2:14:50 PM *Subject: *Re: Intent to implement: navigator.deviceStorage On Wed, Jul 16, 2014 at 9:08 PM, Dave Hylands dhyla...@mozilla.com mailto:dhyla...@mozilla.com wrote: Currently, we have navigator.getDeviceStorage and navigator.getDeviceStorages We're looking to expand device storage to add support for more virtual storage areas, like DropBox, or GoogleDrive, etc. See bug 1035053 I was going to propose that we add navigator.deviceStorage (or possibly navigator.mozDeviceStorage) and have at least the following methods: deviceStorage.addObserver deviceStorage.removeObserver addObserver/removeObserver are Gecko-isms that don't really have a counterpart in Web APIs. Why not use an EventListener? No reason, other than I'm not familiar with EventListener. What is an EventListener and how would you use it? Maybe just point me at an example? What David and Ralph said! You can grep dom/webidl for EventListener to find many examples of this. Also, see EventTarget. deviceStorage.getAll deviceStorage.getDefault We need some new notifications, one to report when the default volume has changed (on B2G it is controlled by a setting which then gets reflected into a preference), one to report when a new storage area (like DropBox) is added, and one to report when it goes away. Presumably we'd also need additional APIs to actually add/remove storage areas. deviceStorage.getAll would return exactly what navigator.getDeviceStorages returns today, and deviceStorage.getDefault would return exactly what navigator.getDevicetorages returns today. I think that we probably need to leave getDeviceStorage and getDeviceStorages both around for the time being in order to maintain backwards capability. So getAll/getDefault would be exactly like getDeviceStorage()/getDeviceStorages? If so, I'm not really sure what we gain from this renaming... We need someway to add listeners for the default storage area changing and for new storage areas coming and going, and possibly even for an API to add/remove storage areas. So it felt to me that having a new entity called deviceStorage with all of the device storage functionality contained within it seemed more natural to me than adding several more free functions into the namespace. I don't really have an opinion one way or the other. I'd just like to move things along in a decent direction, but I just don't know what that means. Ah I see. I think that your intent is pure, but changing the API like this will break existing apps that rely on it. Perhaps adding an EventListener on Window would be enough, so that we can keep the same API? (Also, please see Marco's email about this to dev-webapi. It would be nice if we could coordinate our efforts here.) Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform One of the unfortunate design flaws in the current API is the combination of using event listeners and the getDeviceStorage getter returning a new object every time. Once an event listener is added to the object it is rooted for essentially the lifetime of the window because it has to listen to notifications from the filesystem. And you get a new one every time (which you basically have to do since you can only have a single event *handler (as opposed to event listeners)). We've seen automated testing runs that use the phone for a while ending up with hundreds or thousands of rooted DeviceStorage objects. See bug 985197 for the details. I would like to ensure that we don't make the same mistakes again. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Building with a RAM disk
Today I tried to build Firefox on a RAM disk for the first time, and although I succeeded through trial and error, it occurs to me that there are probably things I could do better. Could someone who regularly does this make a blog post or an MDN page about their workflow and some tips and tricks? I think it'd be useful to many people but I (read: Google) couldn't find anything helpful. Thanks! GL ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Building with a RAM disk
What OS are we talking about? (On Linux, ramdisks are mountpoints like any other so that would be trivial; but then again, on Linux, the kernel is good enough at using extra RAM for disk cache automatically, that you get the benefits of a RAMdisk automatically). Benoit 2014-07-18 22:39 GMT-04:00 Geoff Lankow ge...@darktrojan.net: Today I tried to build Firefox on a RAM disk for the first time, and although I succeeded through trial and error, it occurs to me that there are probably things I could do better. Could someone who regularly does this make a blog post or an MDN page about their workflow and some tips and tricks? I think it'd be useful to many people but I (read: Google) couldn't find anything helpful. Thanks! GL ___ 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
