Why include extApplication.js but using scriptLoader load it?
https://dxr.mozilla.org/mozilla-central/source/browser/fuel/fuelApplication.js#817 #include ../../toolkit/components/exthelper/extApplication.js -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linked Data must die. (was: Linked Data and a new Browser API event)
On Sat, Jun 27, 2015 at 5:51 AM, Marcos Caceres mar...@marcosc.com wrote: These look fantastic! so why not start with just those? Or are all those card types done and thoroughly tested on a good chunk of Web content? As I mentioned before, I'd be worried about the amount of error recovery code that will be needed just for those types of cards. (Sorry, I don't know any of the background and if you've already dealt with this). We will definitely start with the simple open graph stuff that Ted mentioned (og:title, og:type, og:url, og:image, og:description) since they are so widely used. And yes, even these simple ones are problematic. For instance, when navigating between dailymotion videos they keep the current meta tags, and just updates the html body content. In fact, single-page-apps in general are hard here. Also, on the mobile version of youtube they leave out og tags entirely, probably as a performance optimization. Turns out, many sites do this. So in 2.5 we will have to account for all of this and the solution might not be pretty. I think Microformats addresses the aforementioned problems. But if youtube, wikipedia, pinterest, twitter, facebook, tumblr, etc don't use them widely what is the point of supporting them in a moz-internal API? Let's be pragmatic and start with og. What's the next biggest win for us? Is the data clear? Ben seems to think JSON-LD [1], does anyone have data to the contrary? 1.) https://groups.google.com/d/msg/mozilla.dev.platform/5sUoRTPDnSE/24ckuPSydjQJ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sun, Jun 28, 2015 at 10:09:04PM +0200, David Rajchenbach-Teller wrote: On 28/06/15 20:39, Randell Jesup wrote: I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. That's right, but we also tested e10s in the process-per-tab configuration There are other options for background tab effects on foreground, though all have some sort of impact. (For example, you could 'freeze' background tabs more aggressively than we currently do. This may have some impact on functionality - we already limit timeouts, but IIRC we don't turn them off entirely, and other events still occur that we could defer until the tab is touched or ignore - but again, that could cause sites to break or make switching back problematic/annoying. However, I'm out of touch with the exact state of our 'freezing' of background tabs. And there are certainly sites where they'll eat your performance (eventually) unless you block everything. Actually, I was just thinking about introducing a priority-to-60fps mode, activated e.g. while the user is scrolling the foreground tab, or perhaps during animations in the foreground tab. Whenever we are running in priority-to-60fps mode, we can delay up to N milliseconds main thread treatments such as: - garbage-collection/cycle-collection; - dispatching events to background tabs (including timeouts); - Session Restore; - Thumbnail creation; - FHR; - Sync; - db flushes; - copying large batches of data to worker threads; - performance monitoring; - ... BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. That's right, but we also tested e10s in the process-per-tab configuration There are other options for background tab effects on foreground, though all have some sort of impact. (For example, you could 'freeze' background tabs more aggressively than we currently do. This may have some impact on functionality - we already limit timeouts, but IIRC we don't turn them off entirely, and other events still occur that we could defer until the tab is touched or ignore - but again, that could cause sites to break or make switching back problematic/annoying. However, I'm out of touch with the exact state of our 'freezing' of background tabs. And there are certainly sites where they'll eat your performance (eventually) unless you block everything. Have we ever considered building something like the unload tab addon into the platform or Firefox directly? We have talked about it (BarTab Heavy is another example) and the code that Yoric wrote for measuring per-compartment main-thread CPU-usage in about:performance could be used for this. It's unclear how to prioritize it though because doing 100% reliable heavy tab detection will require non-trivial effort (see issues with slow-addon info bar) and the background tab problem will mostly be mitigated by process-per-tab e10s. The problem with auto-unloaders is that you don't want that for some sites - real context or data can be lost. Yes, you can let users white-list things, but only (some) power users would even realize that this is an option or needed. I think serious care needs to be given when thinking of this as a default (or even as a particularly easy option). I think flagging sites as causing slowdown/etc is a great thing and good first step, which puts the control in the user's hands. A nice fire animation on the tab perhaps? ;-) Seems we used to have those in tinderbox https://addons.mozilla.org/en-US/firefox/addon/unloadtab/ An essential add-on for power users that have many tabs open. Curb your resource usage by unloading tabs that you haven't visited for a while. An unloaded tab is restored back to its original state when you need it again. original state likely doesn't include sites that dynamically modify themselves, which is a lot of sites. -- Randell Jesup, Mozilla Corp remove news for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Mon, Jun 29, 2015 at 06:23:30AM +0900, Mike Hommey wrote: On Sun, Jun 28, 2015 at 10:09:04PM +0200, David Rajchenbach-Teller wrote: On 28/06/15 20:39, Randell Jesup wrote: I was under the impression that because e10s is only a single process for all content (at least right now) a background tab can still negatively affect the foreground tab. That's right, but we also tested e10s in the process-per-tab configuration There are other options for background tab effects on foreground, though all have some sort of impact. (For example, you could 'freeze' background tabs more aggressively than we currently do. This may have some impact on functionality - we already limit timeouts, but IIRC we don't turn them off entirely, and other events still occur that we could defer until the tab is touched or ignore - but again, that could cause sites to break or make switching back problematic/annoying. However, I'm out of touch with the exact state of our 'freezing' of background tabs. And there are certainly sites where they'll eat your performance (eventually) unless you block everything. Actually, I was just thinking about introducing a priority-to-60fps mode, activated e.g. while the user is scrolling the foreground tab, or perhaps during animations in the foreground tab. Whenever we are running in priority-to-60fps mode, we can delay up to N milliseconds main thread treatments such as: - garbage-collection/cycle-collection; - dispatching events to background tabs (including timeouts); - Session Restore; - Thumbnail creation; - FHR; - Sync; - db flushes; - copying large batches of data to worker threads; - performance monitoring; - ... BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? Speaking of threads, do we already fiddle with thread priorities so that the OMTC thread possibly gets more time slices? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey m...@glandium.org wrote: BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? If you are referring to bug 715376 (and related), those patches are still in my queue, fully rebased. We only need to decide that it's worth spending a significant amount of time addressing the test failures induced by those patches (see comment 109 in that bug, for instance) and the possible webcompat issues from those patches. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sun, Jun 28, 2015 at 5:14 PM, Nathan Froyd nfr...@mozilla.com wrote: On Sun, Jun 28, 2015 at 5:23 PM, Mike Hommey m...@glandium.org wrote: BTW, wasn't there an effort a few couple years ago, to move content event loop in different threads for different tabs? What happened to that? If you are referring to bug 715376 (and related), those patches are still in my queue, fully rebased. We only need to decide that it's worth spending a significant amount of time addressing the test failures induced by those patches (see comment 109 in that bug, for instance) and the possible webcompat issues from those patches. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform I believe he's referring to supersnappy. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sunday, June 28, 2015 at 4:09:18 PM UTC-4, David Rajchenbach-Teller wrote: Actually, I was just thinking about introducing a priority-to-60fps mode, activated e.g. while the user is scrolling the foreground tab, or perhaps during animations in the foreground tab. Whenever we are running in priority-to-60fps mode, we can delay up to N milliseconds main thread treatments such as: - garbage-collection/cycle-collection; - dispatching events to background tabs (including timeouts); - Session Restore; - Thumbnail creation; - FHR; - Sync; - db flushes; - copying large batches of data to worker threads; - performance monitoring; - ... I asked Avi to work on pausing GC/CC during scrolling in Q3 Q4 2014. I still think it's relevant but process-per-tab will give some of the same benefits ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing the Content Performance program
On Sun, Jun 28, 2015 at 7:55 PM, Vladan D vdje...@mozilla.com wrote: I asked Avi to work on pausing GC/CC during scrolling in Q3 Q4 2014. I still think it's relevant but process-per-tab will give some of the same benefits Olli is working on creating some kind of unified scheduler for the giant mess of GC and CC timers we currently have, in bug 1168991. This will make it much easier to pause things during scrolling. 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
