Re: RFC: Navigation transitions
On Tue, Apr 28, 2015 at 4:26 AM, Jonas Sicking jo...@sicking.cc wrote: This is awesome!! I completely agree that the Google proposal is much too complicated for an initial take on solving transitions. I agree with Anne that this should be doable by adding CSS rules to a normal stylesheet rather than using a special linking mechanism. If that sounds good to you, then it would probably be worth updating the examples in the proposal to reflect this (don't worry about suboptimal names for now). Yes, good idea - there are a few other things I'd like to amend too, but I need to discuss with some platform people to know what's feasible and what isn't. I do have a few questions, but generally this looks great! * Is it always the right decision to have the new page render on top of the old one? Are there situations when you'd want, for example, the old page to slide away and have the new one appear underneath? You could for example create the effect of turning page in a book if the old page folds forward with the new page appearing behind it. One problem though would be how the old and the new page would negotiate which should appears on top, and which should appear on bottom. Yes, I think you're right - I considered this after, and it would be good to have a way of specifying z-ordering... Perhaps in that @viewport block that Anne suggests? * Is it worth making it possible to animate the viewport in/out rather than just style the various elements in the page? For example if you want the new page to slide in from the right you have to not just animate the body element. You also have to animate any position:absolute and position:fixed elements. Maybe this would be best solved as an orthogonal feature which allows applying CSS transformations to the viewport. An orthogonal feature for this would be nice I think. Ideally, you'd be able to just put an animation on the html element and that's what would happen. I think it's good to change as little as possible in this spec though. * We probably should add some form of API which allows the loading page to indicate when it's ready to be rendered. I.e. when the browser should start triggering the animate-in/out animations. This page is ready to be rendered feature has come up in several other contexts but seems extra important here. This would be nice, but I think it could be an orthogonal feature again. Perhaps a feature that lets the page itself control loading progress? I think that'd make a lot of sense. * I think we should make sure that this proposal doesn't make the feature Google ask for impossible to add in the future. I don't think the current proposal does, but it might be worth explicitly saying that that can be added in the future, rather than to just say that it's impossible right now. Which feature are you referring to here? Being able to interleave from/to document elements? I'm open to any ideas about this, but I think being able to do so would make implementation much harder, so I'd certainly like to avoid it in an initial draft at least. All in all, this is super awesome. Please do push for it at the W3C! / Jonas Thanks for the feedback, this is great :) --Chris On Thu, Apr 23, 2015 at 3:39 AM, Christopher Lord cl...@mozilla.com wrote: Seems it has, sorry about that - here's a new one: http://chrislord.net/?p=273preview=1_ppp=d17048fbc3 I plan on publishing this (on my blog) today. The proposal and shim source is also visible permanently in git: https://gitlab.com/Cwiiis/gaia-navigator On Thu, Apr 23, 2015 at 5:23 AM, Ting-Yu Chou tc...@mozilla.com wrote: On Wed, Apr 22, 2015 at 1:02 AM, Christopher Lord cl...@mozilla.com wrote: down. I'm not a huge fan of all aspects of their proposal, so I've made my own: http://chrislord.net/?p=273preview=1_ppp=0afe20d87f Seems the link is outdated? ___ 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: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On Tue, Apr 28, 2015 at 4:07 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Well, we're not talking about changing C++. ;-) My understanding is that the C++ committee will never change the meaning of existing programs without extremely compelling reason, so if override currently implies virtual, I think we can safely assume that will never be changed. But why do you find it more clear to say |virtual ... final| than |... final|? They both convey the exact same amount of information. Is it just habit and/or personal preference? Personally, I was surprised when I first learned that override/final can only be used on virtual functions. I was definitely unaware that override/final imply virtual until I read this thread. It seems David Baron also didn't know. So I think keeping virtual makes things clearer for people who aren't C++ gurus like you. :) I would wager that most of our developers would not realize that void foo() override; is a virtual function, especially if they didn't think about it much. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Java Deployment Kit block
Hi There, The block placed on the Java Deployment Kit seems to affect other plugins such as Flash. I was using Nightly 64-bit as my web browser and have observed that in the past few days, Adobe Flash seems to not work even though I have it set to always enabled. The only plugin disabled in my browser is the Java Deployment Kit due to a bug report. Please have a look into this as it seems to affect other users as shown in the comments for the bug report. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Java Deployment Kit block
On 04/28/2015 04:16 PM, Dhon Buenaventura wrote: Hi There, The block placed on the Java Deployment Kit seems to affect other plugins such as Flash. I was using Nightly 64-bit as my web browser and have observed that in the past few days, Adobe Flash seems to not work even though I have it set to always enabled. I don't think this has anything to do with Java. You're likely hitting this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1158270 At least, I saw similar issues (flash being aggressively blocked) over the past few days, and that ended up being the bug I was hitting. That particular bug is fixed as of the Nightly that went out this morning. So, with any luck, your issue should be fixed if you update to the latest nightly. If you're still having trouble, please file a bug here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Corecomponent=Plug-ins Thanks, ~Daniel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used
On Tue, Apr 28, 2015 at 3:52 AM, Aryeh Gregor a...@aryeh.name wrote: Personally, I was surprised when I first learned that override/final can only be used on virtual functions. I was definitely unaware that override/final imply virtual until I read this thread. It seems David Baron also didn't know. So I think keeping virtual makes things clearer for people who aren't C++ gurus like you. :) I would wager that most of our developers would not realize that void foo() override; is a virtual function, especially if they didn't think about it much. It's not that much of a stretch to imagine that override and final only make sense with virtual functions. I would like exactly one permissible syntax. The one that Ehsan has proposed is the cleanest. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: RFC: Navigation transitions
On Tue, Apr 28, 2015 at 6:49 AM, Christopher Lord cl...@mozilla.com wrote: On Tue, Apr 28, 2015 at 4:26 AM, Jonas Sicking jo...@sicking.cc wrote: This is awesome!! I completely agree that the Google proposal is much too complicated for an initial take on solving transitions. I agree with Anne that this should be doable by adding CSS rules to a normal stylesheet rather than using a special linking mechanism. If that sounds good to you, then it would probably be worth updating the examples in the proposal to reflect this (don't worry about suboptimal names for now). Yes, good idea - there are a few other things I'd like to amend too, but I need to discuss with some platform people to know what's feasible and what isn't. Sounds good. I do have a few questions, but generally this looks great! * Is it always the right decision to have the new page render on top of the old one? Are there situations when you'd want, for example, the old page to slide away and have the new one appear underneath? You could for example create the effect of turning page in a book if the old page folds forward with the new page appearing behind it. One problem though would be how the old and the new page would negotiate which should appears on top, and which should appear on bottom. Yes, I think you're right - I considered this after, and it would be good to have a way of specifying z-ordering... Perhaps in that @viewport block that Anne suggests? The question is, who decide which page goes on top? Specifically, what if both the outgoing and the incoming page request being on top? Or if both explicitly request being on bottom. I guess we simply need to define a winner in that case. * We probably should add some form of API which allows the loading page to indicate when it's ready to be rendered. I.e. when the browser should start triggering the animate-in/out animations. This page is ready to be rendered feature has come up in several other contexts but seems extra important here. This would be nice, but I think it could be an orthogonal feature again. Perhaps a feature that lets the page itself control loading progress? I think that'd make a lot of sense. I agree it's an orthogonal feature. I think we'll find that it'll be very hard to do without though. * I think we should make sure that this proposal doesn't make the feature Google ask for impossible to add in the future. I don't think the current proposal does, but it might be worth explicitly saying that that can be added in the future, rather than to just say that it's impossible right now. Which feature are you referring to here? Being able to interleave from/to document elements? Yes. Being able to transition, for example, an image element from one to the other. I'm open to any ideas about this, but I think being able to do so would make implementation much harder, so I'd certainly like to avoid it in an initial draft at least. I agree this is significant complexity. So definitely to be avoided in the initial draft. All I'm suggesting is that we explicitly say that it can be added in a later version if that's desired. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing Operation Instrument
This is built on top of the docshell ProfileTimelineMarkers. There is a marker for the start of the traced operation and another for the end of the traced operation. The RAII class mozilla::AutoTimelineMarker simply adds these start and end markers on construction and destruction respectively (but only if the given docshell is being observed by devtools). On Mon, Apr 27, 2015 at 7:17 PM, Robert O'Callahan rob...@ocallahan.org wrote: How is this related to PROFILER_LABELs, docshell ProfileTimelineMarkers, and VisualEventTracer? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: RFC: Navigation transitions
On Tue, Apr 21, 2015 at 10:02 AM, Christopher Lord cl...@mozilla.com wrote: I'd appreciate any feedback (even if it's You're an idiot and this is not how we go about this) before taking this any further. Doesn't this increase the effective page transition latency by adding the animation duration to the page load time? Is there any sense in permitting the -exit transition to occur prior to the new content being ready? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Windows content process sandbox now low integrity by default
Following on from my previous post [1], I have now landed a patch that makes the Windows content process sandbox low integrity by default. (pref: security.sandbox.content.level=1) I know of only one regression that this causes at the moment. This is that printing using the Microsoft XPS Document Writer or selecting Print to file fails (Bug 1156742). Due to this problem, this is a Nightly only change at the moment and will not currently move to Aurora when e10s does. If you need this feature, you could temporarily open a non-e10s window and print from there. If you use it a lot, then you can go back to the previous default (pref: security.sandbox.content.level=0), which requires a restart. For any other issues caused by this, please file them to block bug 1151767. I know this is stating the obvious :-), but you can test that they are caused by this change by retrying with the previous level 0 default as mentioned above. (Repeated from my previous post) You can turn on limited sandbox logging to the browser console with the pref: security.sandbox.windows.log This doesn't log all the things that the sandbox might block, but it should log things that we might be able to fix by adding new policy rules. You can filter the output with Process Sandbox. Please copy (or attach) anything that looks like it might be relevant into the bug. You can also get a stack trace in the log entry with: security.sandbox.windows.log.stackTraceDepth The logging requires a restart, but changing the stack trace depth should not. Thanks, Bob [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/QaSdtSMGM7c ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: NS_LITERAL_CSTRING
Ehsan Akhgari wrote: On 2015-04-27 6:29 AM, Neil wrote: I found the following in-tree examples, none of which would have worked with NS_LITERAL_STRING: These are terrible! But what should we replace them with? 1. Change all of those static const char arrays back into #define 2. Invent a new wrapper for static const char arrays (NS_TERMINATED_ARRAY?). Would such a string be marked as sharable? 3. Something else? -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Today, 28 Apr 2015 at 1:00pm PDT
The next MemShrink meeting is brought to you by debuggerMallocSizeOf: https://bugzilla.mozilla.org/show_bug.cgi?id=1158257 https://bugzilla.mozilla.org/show_bug.cgi?id=1142183 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, 28 Apr 2015, 1:00 PM PDT * http://arewemeetingyet.com/Los%20Angeles/2015-04-28/13:00/MemShrink%20Meeting http://arewemeetingyet.com/Los%20Angeles/2015-04-14/13: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: Intent to deprecate: Insecure HTTP
On 24/04/15 23:06, Roger Hågensen wrote: On Tuesday, April 21, 2015 at 2:56:21 PM UTC+2, Gervase Markham wrote: This makes checking in with the browser maker a necessary prerequisite for secure connections. That has problems. How so? Certificates have to be checked today as well (if they have been revocated or not). Yes, and this has privacy problems too. Hence the move towards OCSP stapling, which does not. 3. When the user later connect to a server that support automatic encryption, the browser sends a (public) session key that the server should use, this key is signed with the browser installation key, the server can verify the signature and that this key is not modified by checking the certificate server. What you just built is a unique identifier for every browser which can be tracked across sites. How can this be tracked? This can be tracked just like any other client certificate can be tracked currently, no difference. Right. And that's one reason why people don't use client certificates! :-) Client certificates allow users to be tracked with 100% accuracy across every site which requests the cert. Which is why IIRC, by default, users are prompted in Firefox before sending a client certificate. DNSSEC exists and should help mitigate who you are talking to issue. And is not fully deployed, and certainly not where it's most needed, at the endpoints. Also certificates have been falsified (didn't Mozilla just untrust all certificates by a certain certificate issuer recently that allowed fake Google.com certificates to be made?) Sometimes certs are misissued - certs can never be trusted is not good logic. Also with certificates like the free ones from StartSSL the only site identity you can see is identity not verified yet the connection is still HTTPS. The domain name is the site identity for a DV certificate. DNSSEC enabled (does all latest browsers support that?) So one can be relatively sure to be talking to skuldwyrm.no without https. Perhaps, in this one case, if Firefox checked DNSSEC, which it doesn't. But you would have no guarantee of content integrity without HTTPS - an attacker could alter the content during transmission. What I'm proposing is no worse than automatic domain verified certificates currently are. Then why re-engineer the entire secure Internet just to get something which is no worse? Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: RFC: Navigation transitions
It would be good to know how this plays with the visibility api? When does the outgoing document become hidden - at the end of the animation? And likewise for the incoming document. If visibility state is being used for say stopping some media being played, it makes sense to flip the state before animating away from a page. For the incoming page, I guess the same is true - for the purposes of the visibility api, the document is only visible once the animation ends? /Sam On Thu, Apr 23, 2015 at 3:39 AM, Christopher Lord cl...@mozilla.com wrote: Seems it has, sorry about that - here's a new one: http://chrislord.net/?p=273preview=1_ppp=d17048fbc3 I plan on publishing this (on my blog) today. The proposal and shim source is also visible permanently in git: https://gitlab.com/Cwiiis/gaia-navigator ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
