Re: PSA: Upcoming changes to the creation of Necko channels
On 2015年04月03日 13:11, Boris Zbarsky wrote: On 4/2/15 10:27 PM, Ehsan Akhgari wrote: Note that for the network connections that are used for our own purposes which do not belong to a specific web page, this value won't be used, so its value doesn't matter in practice, but as convention, please pass RequestContext::Internal/internal. I assume we'll default to this for channels add-ons end up creating? -Boris Will this also be true for channels for reading e-mail messages from mail store, etc. used by TB? I see the following warnings often during |make mozmill| test suite of C-C TB (by running DEBUG build) when actually it is quite likely that the data being passed is plain text message: TEST-START | /REF-COMM-CENTRAL/comm-central/mail/test/mozmill/attachment/test-attachment-menus.js | test_deleted_attachment ++DOMWINDOW == 105 (0x1a0a100) [pid = 2965] [serial = 116] [outer = 0x27a3260] [2965] WARNING: Failed to retarget HTML data delivery to the parser thread.: file /REF-COMM-CENTRAL/comm-central/mozilla/parser/html/nsHtml5StreamParser.cpp, line 951 TEST-PASS | /REF-COMM-CENTRAL/comm-central/mail/test/mozmill/attachment/test-attachment-menus.js | test-attachment-menus.js::test_deleted_attachment CI CI ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Upcoming changes to the creation of Necko channels
On Fri, Apr 3, 2015 at 4:27 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Next week, I'm planning to land the patches to bug 1149853 which enables Gecko to track which RequestContext a network fetch is being performed for. Are you replacing this existing interface by doing that? https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy Fetch is meant to standardize that existing concept across browsers. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Is there anyway to parse XML in other thread?
I am currently to use XMLHttpRequest to fetch large amount of xml files in main thread but found it's very slow when I fetching multiple document that contains large amount data in the same time. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Bug 706103 should be backed out. Theme authors very unhappy
[quote] This is a ridiculous change: In the chrome.manifest there are now many override's like this: override chrome://global/skin/popup.css chrome://global/skin/popup-aero.css osversion=6 For custom themes these override are a nightmare. Custom themes are not allowed to do overrides, but now we have to include files such as popup-aero-css.css in our theme importing the normal popup.css just to be able to restore normal order again. This impacts ALL customs themes enormously. This needs to be reverted and another solution is to be found for this than using overrides in this way. [/quote] [quote] Dão Gottwald [:dao] 2015-04-03 01:16:22 PDT Alfred, please read the bug before commenting, and don't reopen bugs you don't own. [/quote] Really? Nobody can reopen a bug except the owner? Phil [thinks some more] actually this might come in handy. If some idiot tries to reopen one of my bugs, I can always slap them down and tell them this is Mozilla policy. Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is there anyway to parse XML in other thread?
I think you can use XMLHttpRequest in a worker, so that everything happens in the separate thread. - Xidorn On Fri, Apr 3, 2015 at 8:40 PM, Yonggang Luo luoyongg...@gmail.com wrote: I am currently to use XMLHttpRequest to fetch large amount of xml files in main thread but found it's very slow when I fetching multiple document that contains large amount data in the same time. ___ 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: Is there anyway to parse XML in other thread?
On 4/3/15 8:35 AM, Xidorn Quan wrote: I think you can use XMLHttpRequest in a worker This actually proxies all the work to the main thread. The answer to the original question is that all the DOM code is very much main-thread-only right now. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is there anyway to parse XML in other thread?
On 4/3/15 9:31 AM, 罗勇刚(Yonggang Luo) wrote: Don't know if we can compile c expat to asm.js to running in a worker. If you just want an XML parser in JS, there are various options out there which are significantly more usable (and possibly faster) than trying to shoehorn expat into JS. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Upcoming changes to the creation of Necko channels
On Fri, Apr 3, 2015 at 4:27 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Next week, I'm planning to land the patches to bug 1149853 which enables Gecko to track which RequestContext [1] a network fetch is being performed for. This will enable us to correctly signal the context for which a given request was made to service workers that intercept the corrresponding network connection. This requires modifying the C++ and JS APIs for creating Necko channels. The changes to the callers is straightforward, you pass the value that describes the kind of network request you're making (for example, whether it's being used for an image, a stylesheet, or loading an iframe, etc.) in the form of a member of the mozilla::dom::RequestContext enum, or a string from the WebIDL enum. Note that for the network connections that are used for our own purposes which do not belong to a specific web page, this value won't be used, so its value doesn't matter in practice, but as convention, please pass RequestContext::Internal/internal. (Note to comm-central maintainers: unfortunately I won't have the time to look into the comm-central consumers for this one, since the fixes especially to JS code will require manual testing, it would be great if you can start with applying my patches on mozilla/ and update the comm-central consumers. For comm-central, you can always use the internal value.) We've recently done work to make all code which create necko channels pass in a nsIContentPolicy type. This maps very closely to request context types. Would be good if we could leverage the work already done and also avoid having to pass in two types. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is there anyway to parse XML in other thread?
Thanks for your help, even though XMLHttpRequest 's responoseXml is always be null. Don't know if we can compile c expat to asm.js to running in a worker. 2015-04-03 20:35 GMT+08:00 Xidorn Quan quanxunz...@gmail.com: I think you can use XMLHttpRequest in a worker, so that everything happens in the separate thread. - Xidorn On Fri, Apr 3, 2015 at 8:40 PM, Yonggang Luo luoyongg...@gmail.com wrote: I am currently to use XMLHttpRequest to fetch large amount of xml files in main thread but found it's very slow when I fetching multiple document that contains large amount data in the same time. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Inconsistent theme policy
Redirecting this to firefox-dev, which is more appropriate. Gavin On Fri, Apr 3, 2015 at 9:33 AM, Philip Chee philip.c...@gmail.com wrote: Let's take for instance: Bug 1150006 - Get rid of -aero file name suffixes, part 4: replace some Windows icons with Gtk stock icons on Linux. Once upon a time on Linux Firefox would try to look like a native (GNOME) application as much as possible so stock GTK icons were used as much as possible. Some time later someone else decided that this wasn't working and that, on Linux at least, Firefox would look like Firefox no matter what OS/GNOME theme the user had and all the GTK stock icons were replaced by custom icons - like OSX and Windows. Now we're going back, at least in this instance, to using *some* GTK icons. And now we're half and half. If the user changes their Gnome theme, some icons in Firefox would change but not others. [Has anyone tested to see how these changes look like on a non-default Gnome desktop?] Now I don't care personally, not being a Linux user, but we should be consistent one way or the another. In the longer term I think that /themes/ needs a strong module owner, someone who can set a clear direction and is not afraid to enforce it. [Aside] Is anyone here on Linux using the GNOMERunner theme? If so what is your opinion on it? Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ 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: Is MOZ_SHARK still used?
We recently ran numbers on our user base (like about 3 weeks ago), and found that 10.10, 10.9 and 10.6 all had greater than 10% share of our Mac user base. 10.6 was still close to 19%. Syd Polk sp...@mozilla.com +1-512-905-9904 irc: sydpolk On Apr 2, 2015, at 17:45, Mike Hommey m...@glandium.org wrote: On Thu, Apr 02, 2015 at 05:54:38PM -0400, Jeff Muizelaar wrote: I don't think Shark runs on any modern macs. That's a good angle to look from: Shark has not been available since 10.7, and Instruments, which superseded it is available on 10.5 and later. So if someone is using shark, they must be doing that on 10.6 (which is still a supported platform) and could be using Instruments instead. But the population trying to profile on 10.6 must be very slim by now. Mike ___ 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: Network 'jank' - get your blocking IO off of STS thread!
it sounds like overbite is using it as intended. On Fri, Apr 3, 2015 at 2:19 PM, Cameron Kaiser ckai...@floodgap.com wrote: On 3/26/15 8:37 AM, Randell Jesup wrote: Can we stop exposing the socket transport service's nsIEventTarget outside of Necko? If we move media/mtransport to necko... or make an exception for it (and dom/network/UDPSocket and TCPSocket, etc). Things that remove loaded footguns (or at least lock them down) are good. Glad the major real problem was too-similar-names (I'd never heard of STREAMTRANSPORTSERVICE (or if I had, it had been long-forgotten, or mis-read as SOCKETTRANSPORTSERVICE)). The OverbiteFF (gopher and legacy protocols) add-on uses nsISocketTransportService to open sockets, and I'm sure it's not the only one that does. The implementation is non-blocking, but I want to clarify from the above post that the intention is not to block non-Necko consumers from using it. Is this acceptable usage, or is it deprecated? Cameron Kaiser ___ 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: Is MOZ_SHARK still used?
On 4/3/15 12:57 PM, Syd Polk wrote: We recently ran numbers on our user base (like about 3 weeks ago), and found that 10.10, 10.9 and 10.6 all had greater than 10% share of our Mac user base. 10.6 was still close to 19%. Right, but the question is how many people on 10.6 are (1) compiling Firefox themselves and then (2) profiling it with Shark. And also (3) Using our custom profiling hooks from script. I bet the answer is approximately 0 just for item #3, and all the people I know who fall into that bucket are no longer using Shark. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Network 'jank' - get your blocking IO off of STS thread!
On 3/26/15 8:37 AM, Randell Jesup wrote: Can we stop exposing the socket transport service's nsIEventTarget outside of Necko? If we move media/mtransport to necko... or make an exception for it (and dom/network/UDPSocket and TCPSocket, etc). Things that remove loaded footguns (or at least lock them down) are good. Glad the major real problem was too-similar-names (I'd never heard of STREAMTRANSPORTSERVICE (or if I had, it had been long-forgotten, or mis-read as SOCKETTRANSPORTSERVICE)). The OverbiteFF (gopher and legacy protocols) add-on uses nsISocketTransportService to open sockets, and I'm sure it's not the only one that does. The implementation is non-blocking, but I want to clarify from the above post that the intention is not to block non-Necko consumers from using it. Is this acceptable usage, or is it deprecated? Cameron Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
The IndexedDB API does not currently have a way to say no, really, I want to make sure that this important data is saved to disk before I continue. Do our internal APIs offer this? Android can kill Firefox at any time it requires more memory. It seems prudent to at least commit when we're being backgrounded, or you're going to be in the dataloss scenario a hell of a lot of times. -- GCP ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Inconsistent theme policy
Let's take for instance: Bug 1150006 - Get rid of -aero file name suffixes, part 4: replace some Windows icons with Gtk stock icons on Linux. Once upon a time on Linux Firefox would try to look like a native (GNOME) application as much as possible so stock GTK icons were used as much as possible. Some time later someone else decided that this wasn't working and that, on Linux at least, Firefox would look like Firefox no matter what OS/GNOME theme the user had and all the GTK stock icons were replaced by custom icons - like OSX and Windows. Now we're going back, at least in this instance, to using *some* GTK icons. And now we're half and half. If the user changes their Gnome theme, some icons in Firefox would change but not others. [Has anyone tested to see how these changes look like on a non-default Gnome desktop?] Now I don't care personally, not being a Linux user, but we should be consistent one way or the another. In the longer term I think that /themes/ needs a strong module owner, someone who can set a clear direction and is not afraid to enforce it. [Aside] Is anyone here on Linux using the GNOMERunner theme? If so what is your opinion on it? Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: IndexedDB transactions are no longer durable by default, and other changes
On Thursday, April 2, 2015 at 5:01:12 PM UTC-7, Jonas Sicking wrote: We don't fire the commit event until after we've told SQLite to commit and it's come back to tell us that the commit was successful, do we? You mean the complete event, but yes, that's correct. -bent ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 706103 should be backed out. Theme authors very unhappy
On 4/3/15 5:53 AM, Philip Chee wrote: Really? Nobody can reopen a bug except the owner? [thinks some more] actually this might come in handy. If some idiot tries to reopen one of my bugs, I can always slap them down and tell them this is Mozilla policy. I'd instead say that the people doing the work are generally in the best position to decide how to track that work, and that it's been longstanding policy that reopening bugs is almost never the right thing to do [The main exceptions being after a backout, or the rare case of a patch completely failing to fix an issue.] This bug is a good example of that -- it's not helpful to treat Bugzilla as a battleground or tug-of-war using reopening to express complaints. If there's an issue with something that landed, one should either (as appropriate) comment in the bug, file a new bug, or start a thread on the relevant mailing list (firefox-dev in this case). I'll also note that it's not constructive to start things off on a confrontational foot, with labeling like ridiculous and slapping down idiots. Please keep things civil. Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
