Re: How to use jquery in xul files of thunderbird
Hi, Generally, using jQuery in XUL files is not supported. Some of jQuery might work accidentally, but it is designed specifically to work with HTML, not XUL. If you want to write HTML-based add-ons, you should take a look at Jetpack. Cheers, David On 16/07/14 05:38, 王欢 wrote: Dear, When I wanted to use jquery in XUL files, the event was not responded. For example, codes like $(selectorName).hide(500);has no action. If you provide me some documents related, I will be very appreciate. Thanks very much. Best regards, Huan Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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: Studying Lossy Image Compression Efficiency, July 2014
Cool =Re decoding. I'm replying to this note: 1. We're fans of libjpeg-turbo - it powers JPEG decoding in Firefox because its focus is on being fast, and that isn't going to change any time soon. The mozjpeg project focuses solely on encoding, and we trade some CPU cycles for smaller file sizes. We recommend using libjpeg-turbo for a standard JPEG library and any decoding tasks. Use mozjpeg when creating JPEGs for the Web. Why not use hardware for JPEG? It uses less memory, and battery as well as being quicker. It's available on many devices these days too. Why use the CPU to first convert a small amount of data into a big amount of data when it's not needed by most hardware? Not only that, but you probably store the original JPEG data in cache as well! The fastest decoder is the one that does nothing. Just let the dedicated JPEG decoding hardware, or the GPU do it. All talk of considering decoding performance is kind of silly considering the JPEG performance could be improved massively. best, ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to use jquery in xul files of thunderbird
On 7/16/14, 2:40 AM, David Rajchenbach-Teller wrote: Hi, Generally, using jQuery in XUL files is not supported. Some of jQuery might work accidentally, but it is designed specifically to work with HTML, not XUL. If you want to write HTML-based add-ons, you should take a look at Jetpack. Cheers, David On 16/07/14 05:38, 王欢 wrote: Dear, When I wanted to use jquery in XUL files, the event was not responded. For example, codes like $(selectorName).hide(500);has no action. If you provide me some documents related, I will be very appreciate. Thanks very much. Best regards, Huan Wang ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform Many add-ons do use jquery, so it's not impossible to do. I suggest that this discussion is taken to dev.extensions, #extdev on IRC or the add-ons forum: http://forums.mozilla.org/addons/ Regards, Jorge ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: webserial api
Legacy RS232 ports on PC motherboards are probably not that important. But phones, and devices like the Raspberry Pi, and BeagleBone Black, also have native serial ports (i.e. non-USB, non-Bluetooth), and the people that use these types of devices are the very one which are extremely frustrated by the lack of support for access to serial. So don't assume that the web is only used from a PC. Dave Hylands - Original Message - From: Andrew Sutherland asutherl...@asutherland.org To: Jonas Sicking jo...@sicking.cc, Alexandros Chronopoulos achro...@gmail.com, Daniel Veditz dved...@mozilla.com Cc: dev-platform dev-platform@lists.mozilla.org Sent: Tuesday, July 15, 2014 12:01:19 PM Subject: Re: Intent to implement: webserial api On 07/13/2014 11:55 AM, Jonas Sicking wrote: Sadly I don't think that is very safe. I bet a significant majority of our users have no idea what a serial port is or what will happen if they allow a website to connect to it. Agreed. It seems like the concept users are most likely to reliably understand are physical devices. https://github.com/whatwg/serial/issues/23 indicates that that the expected supported underlying layers are USB, Bluetooth, and the random motherboard that still has RS232 ports. As noted in a comment on issue 20 at https://github.com/whatwg/serial/issues/20#issuecomment-28333090 it seems counterproductive to place so much importance on the legacy case. I think an important statement for the spec to make is why it needs to exist at all? Specifically, it seems like both the WebUSB https://bugzil.la/674718 and WebBluetooth https://bugzil.la/674737 specs should both be equally capable of producing the standard stream abstractions supported by the protocols. And then the security and UX can both benefit from the appropriate models. This includes features that the WebSerial API currently can't really offer, like triggering a notification/wake-up/load of the app when the device is reconnected via USB or comes into range of the device, etc. This is arguably a net UX win. Additionally, if the security model involved enumerating vendor/product, not only would it simplify the wake-up notification, but the Firefox OS app marketplace could even suggest apps. (Ex: a system notification could notice you plugged in a specific vendor/product pair for the first time and offer to launch a search. Or tell you what it already found, etc.) Note that I'm not saying the spec/implementation doesn't need to exist. However I do think that from a security/user comprehension perspective WebUSB/WebBluetooth should handle the friendly/easy-to-use stuff and WebSerial needs to be something that needs to be vouched-for by a marketplace or requires the user performing a series of manual steps that would make most people think twice about why they're doing it. Andrew ___ 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: webserial api
On 07/16/2014 02:03 PM, Dave Hylands wrote: But phones, and devices like the Raspberry Pi, and BeagleBone Black, also have native serial ports (i.e. non-USB, non-Bluetooth), and the people that use these types of devices are the very one which are extremely frustrated by the lack of support for access to serial. AIUI the Raspberry Pi/BeagleBone Black/Arduino have GPIO pins that may be hooked up to shields or custom things done by the user and not generic RS232 ports. It seems like in the mapping/definition process, usable identifiers/metadata could be provided that could in turn be surfaced into Firefox/Firefox OS so that authorization could be done in terms of specific things. If there is some emerging serial meta-data protocol so that Firefox OS can send some bytes over the serial port and have the serial port report back what's connected, that's even better. For example: Do you want to allow http://superblinkylights.example.org access to you NeoPixel Shield? I do agree that it would make sense to lump this under the auspices of WebSerial. I think my main point is just that the UX and permissions needs to be about the devices/endpoints. This also seems desirable since otherwise you potentially have to have every app/webpage being smart enough not to use the serial ports that are not hooked up to what it actually wants to talk to. One possibility for this would be for the WebSerial API to have a super-dangerous API surface (that requires app store/configuration pain) and the friendly/safe API. A limited utility app with the super-dangerous permission helps the user define what the random non-self-describing serial ports on their system are. Then all the random show a pretty LED light show on your arduino app can still just ask for the NeoPixel serial protocol/etc. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deploy: plugin timeout A/B test experiment, bug 1018200
This is an official notice of intent to deploy the experiment in bug 1018200 to the beta channel. The experiment is an A/B test to determine the optimal value of the dom.ipc.plugins.unloadTimeoutSecs on the FF32 beta. This setting determines primarily how long we wait to unload Flash and other plugins after a user isn't using it any more while browsing. Users in the experiment will be grouped into 8 equal groups whose timeouts will be set to various values: 0, 5, 15, 30, 60, 90, 120, and 300 seconds. The experiment parameters are: MinVersion: 32.0 MaxVersion: 34.* Start Date: 01-Jul-2014 End Date: 02-Sep-2014 Maximum runtime: 42.0 days Update Channels: beta Sample Rate: 5% Low-priority experiment: this experiment is lower-priority than the translation experiment already scheduled for beta, so any users eligible for that experiment will participate in that one first. A reminder that the experiment system only runs one experiment at a time, so there is no chance of multiple experiments conflicting. To analyze the results I intend after 2-3 weeks to correlate the experiment groups against the telemetry measurement for plugin launch time (bug 1011136). This will tell us both how often users are launching plugins, but also how long those plugin launches take. My intent is to pick a final value for this preference based on the data before we ship FF32 to release. Chad, I'm looking for your approval to use 5% of the beta population for this experiment. Release-drivers, I am looking for your approval to enable this experiment as soon as Kamil completes QA verification on staging. gps, I would like you to take care of getting this experiment deployed to production when everything is ready and monitoring the deployment, since I will be on vacation. I want to thank Qeole, a contributor who implemented the correct timeout setting, the telemetry probe, and this experiment all himself. He/she has done this thoughtfully and well. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: DebugOnly fields aren't zero-sized in non-DEBUG builds
Should we make DebugOnly MOZ_STACK_CLASS? On 2014-07-15, 9:21 PM, Nicholas Nethercote wrote: Hi, The comment at the top of mfbt/DebugOnly.h includes this text: * Note that DebugOnly instances still take up one byte of space, plus padding, * when used as members of structs. I'm in the process of making js::HashTable (a very common class) smaller by converting some DebugOnly fields to instead be guarded by |#ifdef DEBUG| (bug 1038601). Below is a list of remaining DebugOnly members that I found using grep. People who are familiar with them should inspect them to see if they belong to classes that are commonly instantiated, and thus if some space savings could be made. Thanks. Nick uriloader/exthandler/ExternalHelperAppParent.h: DebugOnlybool mDiverted; layout/style/CSSVariableResolver.h: DebugOnlybool mResolved; layout/base/DisplayListClipState.h: DebugOnlybool mClipUsed; layout/base/DisplayListClipState.h: DebugOnlybool mRestored; layout/base/DisplayListClipState.h: DebugOnlybool mExtraClipUsed; gfx/layers/Layers.h: DebugOnlyuint32_t mDebugColorIndex; ipc/glue/FileDescriptor.h: mutable DebugOnlybool mHandleCreatedByOtherProcessWasUsed; ipc/glue/MessageChannel.cpp:DebugOnlybool mMoved; ipc/glue/BackgroundImpl.cpp: DebugOnlybool mActorDestroyed; content/media/MediaDecoderStateMachine.h: DebugOnlybool mInRunningStateMachine; dom/indexedDB/ipc/IndexedDBParent.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBParent.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBParent.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBChild.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBChild.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBChild.h: DebugOnlyRequestType mRequestType; ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: DebugOnly fields aren't zero-sized in non-DEBUG builds
That sounds like a good idea, if possible. 2014-07-16 14:41 GMT-04:00 Ehsan Akhgari ehsan.akhg...@gmail.com: Should we make DebugOnly MOZ_STACK_CLASS? On 2014-07-15, 9:21 PM, Nicholas Nethercote wrote: Hi, The comment at the top of mfbt/DebugOnly.h includes this text: * Note that DebugOnly instances still take up one byte of space, plus padding, * when used as members of structs. I'm in the process of making js::HashTable (a very common class) smaller by converting some DebugOnly fields to instead be guarded by |#ifdef DEBUG| (bug 1038601). Below is a list of remaining DebugOnly members that I found using grep. People who are familiar with them should inspect them to see if they belong to classes that are commonly instantiated, and thus if some space savings could be made. Thanks. Nick uriloader/exthandler/ExternalHelperAppParent.h: DebugOnlybool mDiverted; layout/style/CSSVariableResolver.h: DebugOnlybool mResolved; layout/base/DisplayListClipState.h: DebugOnlybool mClipUsed; layout/base/DisplayListClipState.h: DebugOnlybool mRestored; layout/base/DisplayListClipState.h: DebugOnlybool mExtraClipUsed; gfx/layers/Layers.h: DebugOnlyuint32_t mDebugColorIndex; ipc/glue/FileDescriptor.h: mutable DebugOnlybool mHandleCreatedByOtherProcessWasUsed; ipc/glue/MessageChannel.cpp:DebugOnlybool mMoved; ipc/glue/BackgroundImpl.cpp: DebugOnlybool mActorDestroyed; content/media/MediaDecoderStateMachine.h: DebugOnlybool mInRunningStateMachine; dom/indexedDB/ipc/IndexedDBParent.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBParent.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBParent.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBChild.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBChild.h: DebugOnlyRequestType mRequestType; dom/indexedDB/ipc/IndexedDBChild.h: DebugOnlyRequestType mRequestType; ___ 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 deploy: plugin timeout A/B test experiment, bug 1018200
after a user isn't using it any more How good are we at determining any more? Flash is used in all sorts of crazy ways, and guessing wrong can be more harmful than unloading too soon/late. --Jet ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deploy: plugin timeout A/B test experiment, bug 1018200
On 7/16/2014 3:35 PM, Jet Villegas wrote: after a user isn't using it any more How good are we at determining any more? We start counting when the last instance for that plugin is destroyed (NPP_Destroy). --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: webserial api
I guess my point is that it isn't always possible to determine what device is connected. You need to know the correct baud rate, hardware-flow-control, serial comms to even talk to the device. Some devices are write-only. Some devices are read-only. Some devices aren't even serial devices at all. They might be an IR-LED that you're just bit-banging the RTS line to generate a signal. Here's an example of a write-only device that only uses the DTR signal: http://www.lirc.org/transmitters.html Lots of people use devices like this for controller home theatre systems. Are you going to say you can't use it just because you can't identify the device in a programmatic fashion? Even in the USB serial case, you might just detect that a USB-to-serial dongle is attached and not what device is plugged into the dongle. What about TCPIP-rs232 servers? Nobody seems to care about permissions at the device level for those. Why should you care about permissions just because its connected directly? Dave Hylands - Original Message - From: Andrew Sutherland asutherl...@asutherland.org To: dev-platform@lists.mozilla.org Sent: Wednesday, July 16, 2014 11:25:27 AM Subject: Re: Intent to implement: webserial api On 07/16/2014 02:03 PM, Dave Hylands wrote: But phones, and devices like the Raspberry Pi, and BeagleBone Black, also have native serial ports (i.e. non-USB, non-Bluetooth), and the people that use these types of devices are the very one which are extremely frustrated by the lack of support for access to serial. AIUI the Raspberry Pi/BeagleBone Black/Arduino have GPIO pins that may be hooked up to shields or custom things done by the user and not generic RS232 ports. It seems like in the mapping/definition process, usable identifiers/metadata could be provided that could in turn be surfaced into Firefox/Firefox OS so that authorization could be done in terms of specific things. If there is some emerging serial meta-data protocol so that Firefox OS can send some bytes over the serial port and have the serial port report back what's connected, that's even better. For example: Do you want to allow http://superblinkylights.example.org access to you NeoPixel Shield? I do agree that it would make sense to lump this under the auspices of WebSerial. I think my main point is just that the UX and permissions needs to be about the devices/endpoints. This also seems desirable since otherwise you potentially have to have every app/webpage being smart enough not to use the serial ports that are not hooked up to what it actually wants to talk to. One possibility for this would be for the WebSerial API to have a super-dangerous API surface (that requires app store/configuration pain) and the friendly/safe API. A limited utility app with the super-dangerous permission helps the user define what the random non-self-describing serial ports on their system are. Then all the random show a pretty LED light show on your arduino app can still just ask for the NeoPixel serial protocol/etc. Andrew ___ 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: webserial api
On Jul 16, 2014 10:34 PM, Dave Hylands dhyla...@mozilla.com wrote: I guess my point is that it isn't always possible to determine what device is connected. You need to know the correct baud rate, hardware-flow-control, serial comms to even talk to the device. Some devices are write-only. Some devices are read-only. Some devices aren't even serial devices at all. They might be an IR-LED that you're just bit-banging the RTS line to generate a signal. Here's an example of a write-only device that only uses the DTR signal: http://www.lirc.org/transmitters.html Lots of people use devices like this for controller home theatre systems. Are you going to say you can't use it just because you can't identify the device in a programmatic fashion? Even in the USB serial case, you might just detect that a USB-to-serial dongle is attached and not what device is plugged into the dongle. What about TCPIP-rs232 servers? Nobody seems to care about permissions at the device level for those. Why should you care about permissions just because its connected directly? We are in fact currently caring about security for those right now since we do not expose raw TCP sockets to normal webpages (which as I understand it is what's being debated here). However obviously don't expose it is a pretty terrible way of handling it. Am I correct in saying that the target audience for this is hardware hackers that are doing development at home. And who want to use the web to control hardware that they themselves hack hooked up to their own computer? If so, one option is to simply control this through an nsIPermissionManager permission. This way there would be no UI in default Firefox for enabling access to this API. However anyone could develop a trivial add-on which enabled configuring individual websites to have access to the API. So someone that wants to use this API could simply use such an add-on to enable the API once and for all for their own website. Of for a friends website. However average users would not really be at risk for being tricked into enabling this API and get their system compromised. This also makes it trivial to enable the API for privileged apps in FirefoxOS or desktop (where I believe privileges apps have now been implemented). / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: Fetch specification
Hello, Summary: The Fetch specification unifies fetching across the web platform. The intention of Bug 1039846 is to implement the content facing aspects of the Fetch specification, namely: - Request/Response/Headers/FetchBodyStream objects - Expose the fetch() method on windows and workers. fetch() is a more granular, Promise-based, easy to use form of XHR. ServiceWorkers also rely on the specification since they use these Requests and Responses to provide valid responses to network interception of resource requests from the pages they control. Some of the underlying infrastructure will also be used by the Cache/FetchStorage API exposed to ServiceWorkers. Bug: https://bugzil.la/1039846 Link to standard: http://fetch.spec.whatwg.org Platform coverage: Android, Desktop, Firefox OS Estimated or target release: Firefox 36 Preference behind which this will be implemented: dom.fetch.enabled ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: navigator.deviceStorage
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 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 I guess I'd like to determine if the approach I've outlined is reasonable, and I'd like to get an opinion on whether we should use deviceStorage or mozDeviceStorage. Thanks Dave Hylands ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
