Re: quick! use lisp! before it's too late!

[Tim]

On Wednesday, 15 August 2012 13:46:59 UTC+12, pedb...@gmail.com  wrote:
 Linus Torvalds flamed C++.
 
 - http://article.gmane.org/gmane.comp.version-control.git/57918
 
 
 
 Paul Graham said his company moved faster than its competition, because his 
 company used Lisp.
 
 - http://www.paulgraham.com/avg.html
 
 
 
 Design Patterns are solutions to problems, but the problems shouldn't have 
 happened in the first place.
 
 - me
 
 
 
 Use Lisp!

Anyone got any nice ascii art trophies? 'Cause this is easily the post of the 
year. ;-) No comedy contest!

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Robohornet browser benchmark

[Tim]

Oops, here's the benchmark site:

http://www.robohornet.org/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Robohornet browser benchmark

[Tim]

On Tuesday, 25 September 2012 17:42:00 UTC+12, Nicholas Nethercote  wrote:
 On Mon, Sep 24, 2012 at 5:22 PM,  wrote:
 
  So there's a new benchmark out, seemingly from google.
 
 
 
  It is designed to test performance in web app bottlenecks, especially DOM, 
  canvas API methods, SVG.
 
 
 
  Paul Irish from Google's Chrome team is in charge of it. He blogged on it 
  here:
 
 
 
  http://paulirish.com/2012/a-browser-benchmark-that-has-your-back-robohornet/
 
 
 
 I'm horrified by this.  Quoting my Hacker News comments
 
 (http://news.ycombinator.com/item?id=4567796):
 
 
 
  Oh god, just when web people were starting to understand how to create good
 
  benchmarks 
  (https://blog.mozilla.org/nnethercote/2012/08/24/octane-minus...),
 
  now we're going back to 1980s microbenchmark hell.
 
 
 
  Doesn't anyone read Hennessy and Patterson any more? The best benchmarks
 
  are real apps, not crappy little microbenchmarks that measure a single 
  thing.
 
 
 
  (Can you hear that thud, thud, thud? It's the sound of me beating my head
 
  against my desk.)
 
 
 
 Also, one of the tests is basically a no-op executed many times
 
 (https://bugzilla.mozilla.org/show_bug.cgi?id=793913#c7).
 
 
 
 Even better, there's a prime numbers calculation test, apparently to
 
 test math.  This is grimly hilarious:  Hennessy and Patterson
 
 specifically cite the Sieve of Erastosthenes as an example of a toy
 
 (and thus crap) benchmark.  Sigh.
 
 
 
 Daniel Buchner is apparently Mozilla's official representative on the
 
 RoboHornet committee of JavaScript experts
 
 (https://github.com/robohornet/robohornet/wiki/Committee-Membership).
 
 I don't know what his role is, but the thought of Mozilla officially
 
 blessing RoboHornet fills me with dread.
 
 
 
 While the suite may push us into some useful improvements, I worry
 
 that we'll end up implementing some stupid benchmarketing features
 
 that we will then carefully have to avoid regressing for the next 10
 
 years.
 
 
 
 Nick

The primes calculation inclusion is particularly odd. Especially when there are 
so many existing (useful) computation/math perf benchmarks.

The original bug requesting the canvas clearing test is here:

https://github.com/robohornet/robohornet/issues/43
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.execCommand(cut/copy)

[tim]

I am not sure if this is the right avenue to raise concern (again) over not 
requiring a prompt.  It seems that user action here implies that a user 
intended on having their clipboard destroyed intentionally. (Like requesting a 
SHA from GitHub).

However, I created a very basic demo here: http://jsfiddle.net/azgugmjb/3/ that 
shows how easy (in Chrome 43) it is to abuse the user action.  I really hope 
this shines some light on the potential for real world abuse.  The user action 
in my demo is simply highlighting text.  The use of `.select()` prevents the 
user from actually using the system keybinding for copying and will inject into 
their clipboard something other than what they intended.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

WebRTC Internal IP Address Leakage

[Tim]

Is there any intent at Mozilla to fix this privacy flaw?

https://bugzilla.mozilla.org/show_bug.cgi?id=959893
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: Remove Linux PGO Testing

[Tim Taubert]

On 10/10/2012 11:57 PM, Justin Lebar wrote:
 The main reason I'd want Linux PGO is for mobile.  On desktop Linux,
 most users (I expect) don't run our builds, so it's not a big deal if
 they're some percent slower.  (Unless distros commonly do PGO builds
 of Firefox?)  But we're not doing mobile Linux PGO builds (that I know
 of), and I don't expect success with desktop PGO is much related to
 success with mobile PGO.

You may be right for release builds but that doesn't hold true for
Nightly/Aurora/Beta users. I don't think it's a good idea to make those
builds ~20% slower when of course we want and need more testers. Don't
forget that testers on Linux do not only test Linux-only features but
also features we have on every platform.

Nobody likes running debug builds because they're slower so why would
that be different for non-PGO builds?

Also, I'm not sure how this affects Telemetry results. In terms of perf
measurements we'd probably need to completely ignore everything from
non-release builds as the results might differ heavily for some use
cases.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: Remove Linux PGO Testing

[Tim Taubert]

On 10/11/2012 09:32 AM, Boris Zbarsky wrote:
 The suggestion, as far as I can tell, is to drop Linux PGO completely.
 We woudln't have it in nightly, Aurora, Beta, or releases.  Compiling
 with PGO on Linux would be an unsupported configuration that we'd
 probably advise distros against, because it wouldn't be particularly
 well-tested.

Yes, if we don't distribute PGO builds at all we'd see a one-time bump
and Telemetry is then a non-issue. I was misguided by the thread's
title. If we turn it off for testing we can't ship it.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Revamping touch input on Windows

[Tim Abraldes]

 1) abandon generating nsIDOMSimpleGestureEvents on Windows for both
backends
 when processing touch input from touch input displays.*

 This would mean that if the desktop front end wants to do something with
 pinch or zoom, it would have to process W3C touch events instead. Note
that
 we could still fire simple gestures from devices like track pads. But for
 touch input displays, we would not support these events.

If I understand the proposal correctly, widget would be responsible for
sending only pointer/touch events (with the one exception you
mentioned), and we would implement simple gesture recognition in a js
module.  This would give us a single implementation of gesture
recognition that could be shared and used with multiple widget backends,
and would simplify the widget backends because they no longer have to do
gesture recognition.  For those reasons, I think this is a great idea.

The metro/WinRT widget backend can take advantage of native gesture
recognition, so maybe in the future we would want to implement the
ability to opt-out of front-end gesture recognition. I don't think we
should do this in the immediate term, but as backends get better and
better native support for things like gestures, we may want to allow
ourselves the opportunity to take advantage of that native support.


 2) Rework how we process touch events in Windows widget such that:
 * Both backends respect RegisterTouchWindow and only fire W3C events
when it
 is set.
 * If RegisterTouchWindow has been called:

This is the first I've heard of RegisterTouchWindow, so I can't speak to
whether we should send touch events if it hasn't been called.

 ** Send touchstart and the first touchmove and look at the return results.
 ** If either of these returns eConsumeNoDefault, continue sending W3C
events
 only. No mouse or pixel scroll events would be sent.

Sounds reasonable.

 ** If both of these events do not return eConsumeNoDefault:
 *** Abandon sending W3C touch events.

I'm not sure that we should stop sending W3C pointer/touch events. It's
conceivable that a page exists that is not scrollable, uses touch input,
and does not bother to call `preventDefault` on the pointer/touch events
it receives (which means we won't get eConsumeNoDefault returned).  If a
page is ignoring W3C pointer/touch events anyway, I don't think it is
harmful to keep sending them.

 *** Generate pixel scroll events in the appropriate direction based on
 DecideGestureEvent, or simple mouse events if DecideGestureEvent indicates
 scrolling isn't possible.

We should definitely send scroll events. If scrolling isn't possible, I
don't think we should do anything special; certain mouse events will
already be sent when the user performs non-scroll touches (as per the
W3C specs) and we don't want to start sending a bunch of extra mouse
events all of a sudden.


 There is also the open issue of future support for other touch specs which
 I'm not taking into consideration. If anyone has any input on W3C support
 vs. MS Pointer support I'd love to hear it. I'd hate to get this all
cleaned
 up only to find that we have to change our touch input processing
again for
 the nth time. Maybe now might be a good time to abandon W3C
completely. As I
 understand it MS Pointer events solve some of the problems we have with
 mixed touch/mouse input.

As I understand it, W3C touch events (touchstart/touchmove/touchend) are
the current state of the art, but are being abandoned in favor of W3C
pointer events.  I believe that we should definitely implement W3C
pointer events.  I'm not sure how widespread the usage of W3C touch
events is, but it may be necessary for us to implement those as well for
compatibility.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Revamping touch input on Windows

[Tim Abraldes]

 The metro/WinRT widget backend can take advantage of native gesture
 recognition, so maybe in the future we would want to implement the
 ability to opt-out of front-end gesture recognition. I don't think we
 should do this in the immediate term, but as backends get better and
 better native support for things like gestures, we may want to allow
 ourselves the opportunity to take advantage of that native support.
 
 
 Maybe, if we need to. Currently the metro front end doesn't use most
 of the simple gestures widget sends so might as well disable processing
 and delivery for now. From what I remember we aren't planning on using
 the native cross slide gesture recognizer either. 

That's correct; we're implementing detection of the cross slide gesture
in js in bug 829056 [1].


 ** If both of these events do not return eConsumeNoDefault:
 *** Abandon sending W3C touch events.

 I'm not sure that we should stop sending W3C pointer/touch events. It's
 conceivable that a page exists that is not scrollable, uses touch input,
 and does not bother to call `preventDefault` on the pointer/touch events
 it receives (which means we won't get eConsumeNoDefault returned).  If a
 page is ignoring W3C pointer/touch events anyway, I don't think it is
 harmful to keep sending them.
 
 
 I think we want to enforce the W3C spec. 

The spec doesn't say anything about not sending touch events if
preventDefault wasn't called on the first touchstart/touchmove.

 So for example, say a page is
 listening to touch events and drawing something in response, but fails
 to call preventDefault. Widget on desktop would generate pixel scroll
 events and send touch events. You would have a web page reacting to
 touch events while the browser scrolls.

Page A
  Responds to touch input by drawing
  Does not call preventDefault
  Is scrollable

Page B
  Responds to touch input by drawing
  Does not call preventDefault
  Is not scrollable

If we stop sending touch events when preventDefault isn't called on the
first touchstart/touchmove:
  Page A fails to draw but scrolls correctly
  Page B fails to draw

If we send touch events regardless of preventDefault:
  Page A scrolls correctly but draws while scrolling
  Page B draws correctly

Neither situation is ideal (the page really should call preventDefault
on its touch events) but I think the latter behavior is preferable.

 This is a corner case I think, we could do either and see what bugs
 crop up.

I agree; any page that actually listens for touch events should be
calling preventDefault on those events.


 *** Generate pixel scroll events in the appropriate direction based on
 DecideGestureEvent, or simple mouse events if DecideGestureEvent
 indicates
 scrolling isn't possible.

 We should definitely send scroll events. If scrolling isn't possible, I
 don't think we should do anything special; certain mouse events will
 already be sent when the user performs non-scroll touches (as per the
 W3C specs) and we don't want to start sending a bunch of extra mouse
 events all of a sudden.
 
 
 If we implement sending synth mouse events up in the DOM, great. If not,
 we'll need to deal with it down in widget.

In the metro/WinRT widget backend we handle sending
mousedown/mousemove/mouseup in response to touch input.  It sounds like
we'll want to additionally send scroll events for certain touch input.
I'm not sure how things are handled in the desktop widget backend.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=829056

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Advance warning] Session Restore is changing, will break add-ons

[Tim Taubert]

I talked to Gavin yesterday and we think the best approach would be to
back out the Session Restore changes for now as they don't provide a
real benefit other than code cleanup (and don't block any other work).

The plan would then be to re-land them *with* a kill switch in the same
cycle that brings Australis - so we would need to prepare and keep those
patches ready. The reasoning is that we indeed will break different
add-ons than Australis but at least there will only be one release with
a couple of add-ons breaking instead of two in a row.

For bug 838577 we will probably need to maintain a shadow tree as
Johnathan mentioned. I would suggest we talk to Ehsan as he has
experience in doing this successfully.

- Tim


On 05/22/2013 03:40 PM, David Rajchenbach-Teller wrote:
 Opening Bug 874817 to add that kill switch.
 
 Just for clarification: we might kill add-ons that specifically look at
 the contents of undocumented private data structures. The advance
 warning is here because we know that some such add-ons exist.
 
 Given that all these refactorings take place on a single file, it might
 make sense to just backout the changes if necessary.
 
 Cheers,
  David
 
 On 5/22/13 3:35 PM, Johnathan Nightingale wrote:
 Policy[1] is that whenever something lands on central, it is the
 developer's responsibility to provide for the ability to turn it off.
 Usually that's just a kill switch in cases where it makes sense, or a
 backout where the patch is unlikely to accumulate much change on top of
 itself in a given release.  

 In cases where neither of those works (Ehsan's private browsing changes,
 or dmandelin's landing of ionmonkey in FF18) engineers have had to work
 harder to maintain that ability, e.g. by maintaining a shadow tree that
 doesn't have their patches, but has all the other landings. That's what
 Ehsan's pointing to in his reply.

 I agree with Ehsan that, one way or another, we'll need to be able to
 disable these changes if they cause too much bustage (though I'm very
 happy to know that we're cleaning up that code in general).

 J


 [1] http://mozilla.github.io/process-releases/draft/development_overview/ 
 Ancient,
 and shows it, but still relevant for this case. See Moving work from
 one channel to another

 ---
 Johnathan Nightingale
 VP Firefox Engineering
 @johnath

 
 


-- 
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [b2g] Fix or disable windows desktop b2g builds

[Tim Chien]

I suggest the Apps team should aware of this and potentially invest
some resource into the Windows build, if we want to fully support FxOS
Simulator as a product.

On Fri, Jun 7, 2013 at 2:16 AM, Ben Francis b...@krellian.com wrote:
 On Wed, Jun 5, 2013 at 11:48 PM, Chris AtLee cat...@mozilla.com wrote:

 Windows desktop b2g builds have been pretty broken for several weeks now,
 since around May 24 [1].

 At this week's engineering and b2g meetings we discussed shutting these
 off if nobody has a strong reason to keep them around.


 I have never used the Windows B2G Desktop builds but it you went to an app
 developer day you would see that many third party developers do,
 particularly via the Firefox OS Simulator. They get frustrated that things
 don't work on Windows.

 We should either kill all the B2G Desktop builds (and provide an
 alternative like getting the whole of Gaia to run in Firefox), or get them
 all working. We shouldn't persecute Windows users in particular (even if
 they did make a bad choice :P).

 Ben
 ___
 dev-b2g mailing list
 dev-...@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-b2g



--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: requiring build peer review for Makefile.in changes

[Tim Taubert]

The proposal sounds good to me but I guess you wouldn't want to be
notified of every small addition/change to Makefiles in test
directories? I suppose you're targeting actual changes to dependencies
etc, but where do we draw the line?

Can we maybe add a push hook intelligent enough to separate actual
changes from minor changes that don't need build peer review by scanning
for certain keywords?

- Tim


On 07/18/2013 02:00 AM, Gregory Szorc wrote:
 Traditionally, it's been very difficult for the build peers to keep on
 top of changes in the build config because changes are occurring on bug
 components we don't follow, are touching files all over the tree, and
 because build peers aren't always asked for review.
 
 The potential for sneaking things past build peer review has resulted
 in a number of self-inflicted wounds, the Fennec build rules probably
 being the best example (the dependencies are all wrong and no-op builds
 take ~16s when they should take 1 or 2s).
 
 This history contributed to us implementing a more strict sandbox in
 moz.build files: take away as many footguns as possible and there will
 be less self-inflicted wounds.
 
 Unfortunately, the moz.build conversion isn't finished and it will drag
 on for a while. There will still be Makefile.in in the tree and that
 leaves the door open for new badness.
 
 I would like to reinforce the existing policy: *if you are changing a
 Makefile.in, please ask a build peer for review unless the change is
 just adding or removing to an existing list.*
 
 For the most part, people have been abiding by this policy. However,
 things are still creeping through. Unfortunately, some of them wouldn't
 get r+ from a build peer.
 
 Since new Makefile.in badness makes people's lives harder (especially
 when it makes the build slower), I would like to propose a more strict
 policy around Makefile.in changes: *if a non-list change in a
 Makefile.in isn't reviewed by a build peer, it doesn't land or gets
 backed out.* This could potentially be enforced with repository push hooks.
 
 I /think/ this proposal is supported by our module governance system
 since Makefile.in are the purview of the build config module. But I
 wanted to run the proposal by people to make sure it is generally
 well-received and there aren't any major concerns.
 
 Gregory
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 


-- 
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: requiring build peer review for Makefile.in changes

[Tim Taubert]

On 07/18/2013 02:45 PM, Benjamin Smedberg wrote:
 On 7/18/2013 2:43 AM, Tim Taubert wrote:
 The proposal sounds good to me but I guess you wouldn't want to be
 notified of every small addition/change to Makefiles in test
 directories? I suppose you're targeting actual changes to dependencies
 etc, but where do we draw the line?
 I thought the proposed exception was pretty clear: unless the change is
 just adding or removing to an existing list.

Indeed, it was. Sorry, I must have missed that.

- Tim


-- 
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rethinking separate Mercurial repositories

[Tim Abraldes]

  Sadly, mercurial doesn't support having multiple working directories
  from a single clone, which would be useful to avoid wasting so much
  disk space on .hg.
 
 I'm 85% sure that Mercurial, on filesystems that support it, creates
 hardlinks instead of copies if you hg clone mozilla-central
 mozilla-central-2.

jlebar did a post on how to minimize wasted space in your Mercurial clones:
http://www.jlebar.com/2011/5/20/Faster_and_smaller_clones_of_branches.html
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should the Prevent this page from creating additional dialogs checkbox prevent the page from creating any additional dialogs?

[Tim Abraldes]

Separating and summarizing a little, it sounds like:

For alert/prompt/confirm, we're all (mostly?) agreed that the prevent this 
page from creating additional dialogs checkbox should have its meaning changed 
from rate limit future alert/prompt/confirm to prevent future 
alert/prompt/confirm. In other words, bug 910501 is a valid bug.

For window.print(), we may want to consider a way to prevent the abuse of this 
function. A checkbox, similar to the one for alert/prompt/confirm, is a 
potential option. I imagine that making this a tab-modal dialog as opposed to 
an app-modal dialog would also be beneficial.

For window.showModalDialog(), same comments as for window.print().

If anyone has additional comments on point 1, I'd love to hear them as I have a 
patch that is waiting for the results of this discussion. As for points 2 and 
3, I'd be happy to file bugs and/or start new dev.platform threads. Mark - 
let's coordinate here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should the Prevent this page from creating additional dialogs checkbox prevent the page from creating any additional dialogs?

[Tim Abraldes]

I wrote a reply which I then accidentally sent only to Mark. In any case, we 
chatted in #developers about this.

I'm going to do the following:
  1. Update the patch in bug 856977 (dialogs shouldn't be possible during 
beforeunload) so that it doesn't affect the behavior of the checkbox
  2. Put the checkbox behavior changes into a patch in bug 910501 (checkbox 
should do what it says)
  3. File bugs about separating window.print() and window.showModalDialog() 
from alert/prompt/confirm (in terms of enabled/disabled state for a given page)

If we find that we like the behavior after landing 2, we may never actually 
implement 3. If we don't like the behavior, we can either go ahead and 
implement 3 or back out 2 without affecting 1.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsGUIEvent.h related stuff has been sorted out

[Tim Abraldes]

 I hope this change makes you happy!

It most certainly does! I'm a huge proponent of code cleanup and organization, 
and this looks like a beautiful example of those.


 Finally, the root class, WidgetEvent, has As*Event class. The *
 doesn't include the prefix. I.e., for WidgetMouseEvent, the method name
 is WidgetEvent::AsMouseEvent(). This returns the pointer of the instance
 only when the instance is the class or its derived class. Otherwise,
 returns nullptr.
 
 E.g., WidgetDragEvent is defines as:
 
 WidgetEvent
+- WidgetGUIEvent
 +- WidgetInputEvent
  +- WidgetMouseEventBase
   +- WidgetMouseEvent
+- WidgetDragEvent
 
 If an instance is WidgetDragEvent, AsGUIEvent(), AsInputEvent(),
 AsMouseEventBase(), AsMouseEvent() and AsDragEvent() returns its
 pointer.  The other As*Event() methods return nullptr.
 
 You should not use static_cast for Widget*Event and Internal*Event
 anymore because it may cause wrong casting bug with some mistakes
 (actually, there was such bug!).

I do have a question about this part. It seems that there are 3 distinct 
situations where you might be casting pointers around in this inheritance tree.
  1. Downcasting to a most-derived class (a leaf in the tree)
  2. Downcasting to a non-leaf-node (i.e. a class that is not a most-derived 
class)
  3. Upcasting

For 1 and 3, I believe we can accomplish these safely using static_cast. For 3, 
this is always true. For 1, I believe that the static_cast is safe as long as 
you have checked the |eventStructType| member.
That is, the following should be safe:
  WidgetWheelEvent *event1 = nullptr;
  // Assume that aEvent is a WidgetEvent* that we received from elsewhere
  if (NS_WHEEL_EVENT == aEvent-eventStructType) {
// We can now trust this cast
event1 = static_castWidgetWheelEvent*(aEvent);
  }

For 2, the |eventStructType| member by itself doesn't give us enough 
information to know if a static_cast is safe (you'd have to keep a map of 
most-derived classes to all of their parent classes... yuck). In these cases, I 
feel that the As*Event functions are providing the same functionality as 
dynamic_cast.
That is, the following are equivalent:
  // Assume that aEvent is a WidgetEvent* that we received from elsewhere
  WidgetInputEvent *event2 = aEvent-AsWheelEvent();
  WidgetInputEvent *event3 = dynamic_castWidgetInputEvent*(aEvent);
  // At this point, |event2 == event3| should be true

So my question is this; is it preferable to keep the As*Event functions, or to 
use regular C++ casts to accomplish the same behavior? We could use static_cast 
unconditionally for upcasts, static_cast with a check of |eventStructType| for 
downcasts to most-derived event types, and dynamic_cast for downcasts to 
non-most-derived event types.

I don't think there would be a meaningful performance impact (case 3 would be 
faster, case 2 would be a dynamic cast vs a virtual function call, case 1 would 
be a branch vs a virtual function call), but I think it would clean up our 
event types even further (again, great work cleaning them up this much!) and it 
takes advantage of built-in support from the language to aid us in managing our 
event types.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing a window from the session store

[Tim Taubert]

On 25/10/2013 12:24 PM, Matthew Gertner wrote:
 So if I understand correctly, a window that contains a single private tab 
 will have no visual indication that the tab is private and will also not be 
 restored by the session saver? This would meet my current requirements as 
 long as it's possible to set the tab to private after creation (since I won't 
 know until shutdown whether I want the window to be restored or not).

Private tabs will be automatically excluded when bug 899276 has landed.
I don't know off-hand if setting a tab to private works even if the tab
has been around for some time but I think that might be possible.

 That said, this seems like a worse hack than what I am doing now.

Maybe, yes.

 Why are you getting rid of the nsISupportsString in sessionstore-state-write? 
 Is there some urgency to doing this?

There is no urgency but we're currently in the process of rebuilding
big parts of SessionStore to make it perform better. Giving add-ons that
much access to data makes it really hard to implement any kind of caching.

 Can't you fix https://bugzilla.mozilla.org/show_bug.cgi?id=930713 before you 
 remove it? This seems like a pretty big lack in the current session saver API 
 and something that should be straightforward to implement.

I understand that this feature seems important to you but I disagree
that is a big lack in the current API. This is the first time I hear
of a requirement like that.

Could you maybe describe what you are actually trying to achieve and
why? Is there any add-on code we could take a look at? Maybe we can
together find a different and better solution to your problem.

- Tim



 Cheers,
 Matt
 
 On Oct 25, 2013, at 11:40 AM, David Rajchenbach-Teller dtel...@mozilla.com 
 wrote:
 
 We have partial handling of private tabs. SessionStore doesn't handle
 them yet, but I can prioritize this. Would this be sufficient for your
 needs?

 Cheers,
 David

 On 10/25/13 9:11 AM, Matthew Gertner wrote:
 Can you suggest some other means to do what we need? I don't want to make 
 anyone's life harder but I spent far too long on this problem and didn't 
 come up with another solution.

 Matt
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform



 -- 
 David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 


-- 
Tim Taubert
Firefox Engineer
ttaub...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Central location for tracking known broken build configurations (with bugs)

[Tim Abraldes]

Somebody stop me if this already exists...

I'm envisioning a central location, probably a wiki page at 
https://wiki.mozilla.org/BrokenBuilds or similar, where people can find the 
answers to these questions:
  1. Given my current build configuration, why did my last build fail?
  2. What bugs can I follow to see when this build configuration will work 
again?
  3. What workarounds/patches can I employ to quickly get a working build?

So the page would be a simple table with the following columns: Bug #, affected 
configurations, known workarounds

e.g.
Bug  Affected configurationsKnown 
workarounds
899948   VS (all) with --disable-optimize but not --enable-debug
--without-intl-api
933476   VS (all)   
--disable-webgl
940220   VS2012+
--without-intl-api

The benefits should be obvious; no more IRC logs like the following
  10:40:25 AM - developer1: is there a new build error using obscure-cc other 
than the one developer0 fixed yesterday?
  10:41:15 AM - developer2: developer1: yes, bug 99
  10:42:07 AM - developer3 has joined the room.
  10:42:10 AM - developer3: my builds are failing, but it seems to be a new 
issue. Anyone else seeing this?

Also, no more face-desking if you encounter a known issue while IRC is in a 
lull.

If anyone has reasons *NOT* to create this wiki page, or suggestions for a 
better name or location for this information, please let me know! I'll create 
the page tomorrow if I don't hear from anyone... or maybe today if feedback is 
overwhelmingly positive (or positively overwhelming)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Central location for tracking known broken build configurations (with bugs)

[Tim Abraldes]

 I like where you are coming from.

Yay!

 However, if we know what build bustage is known, it should be codified
 in the tree and the build should abort or you should see a giant
 warning. If we put this information anywhere else, I fear it will become
 out of date very quickly or filled with content that isn't true.

It would be super cool for builds to early-abort if the configuration is known 
to fail! I imagine that the burden for implementing this would land on build 
peers (I certainly don't know enough about the build system to codify something 
like vs2012 fails to build if ICU is enabled). Editing a wiki (or a doc, as 
you mention below) is comparatively easy and could be accomplished by those of 
use who aren't fluent in the build system :)

 A reason why I've been banging on the reproducible build environments
 drum is that if we provide reproducible build environments, that's a
 very quick and easy way to answer is my build environment or my build
 config the thing that's busted?

 Unfortunately, fixing issues like these are often perceived as lower
 importance than making the build faster. I would absolutely love to
 spend a few months on nothing but build UX to help people deal with
 problems like these.

I totally support your efforts in either/both of the above - build UX and 
making the build faster. I'm happy regardless of which one you're working on.

 Possible compromise: have this info live in the tree as part of the
 in-tree docs under build/docs. You need build peer review to update
 those docs and they are versioned with the tree. That addresses my
 accuracy and versioning concerns.

This sounds reasonable to me! The docs would always be up to date with the code 
being built, anyone experiencing an issue can look it up in a known location, 
anyone with knowledge about a particular issue can update the doc, and build 
peers don't have to spend their time keeping config rules constantly up to 
date! Assuming people are on board with this plan, how would we go about 
starting that doc?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Central location for tracking known broken build configurations (with bugs)

[Tim Abraldes]

  Somebody stop me if this already exists...
 
  I'm envisioning a central location, probably a wiki page at
  https://wiki.mozilla.org/BrokenBuilds or similar, where people can find
  the answers to these questions:
1. Given my current build configuration, why did my last build fail?
2. What bugs can I follow to see when this build configuration will work
again?
3. What workarounds/patches can I employ to quickly get a working build?
 
 Sometimes the topic field in #developers contains a link to an
 etherpad describing common kinds of breakage.  Not at the moment,
 though.

That's handy! If we go with the approach suggested by gps, we could move the 
info from the etherpad (does anyone have a link to this etherpad?) into the doc 
as a starting point. In the future we could have the topic of #developers 
explain how to find the doc.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Central location for tracking known broken build configurations (with bugs)

[Tim Abraldes]

  Somebody stop me if this already exists...
 
  I'm envisioning a central location, probably a wiki page at
  https://wiki.mozilla.org/BrokenBuilds or similar, where people can find
  the answers to these questions:
 1. Given my current build configuration, why did my last build fail?
 2. What bugs can I follow to see when this build configuration will
 work
 again?
 3. What workarounds/patches can I employ to quickly get a working
 build?
 
  Sometimes the topic field in #developers contains a link to an
  etherpad describing common kinds of breakage.  Not at the moment,
  though.
 
  That's handy! If we go with the approach suggested by gps, we could move
  the info from the etherpad (does anyone have a link to this etherpad?)
  into the doc as a starting point. In the future we could have the topic
  of #developers explain how to find the doc.
 
 The etherpad was at https://etherpad.mozilla.org/commonissues. Since
 it's been out of the topic since last March, though, I don't think
 anything there is particularly common still.

Thanks for the link! When we have a defined plan I'll update the the etherpad 
to point to a central doc, a bugzilla query, or whatever else we decide on. 
That seems to be the only follow-up necessary here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Central location for tracking known broken build configurations (with bugs)

[Tim Abraldes]

 I would favour a whiteboard tag or keyword on the bug tracking the build
 failure. It should be easy enough to create a query for all open bugs
 with this tag. Usually you want to get to the bug anyway for the latest
 workaround and/or info on what to back out locally.

I'm not opposed to a whiteboard tag or maybe a set of whiteboard tags (so we 
can indicate what configurations are affected). We could even make a wiki page 
that uses the bugzilla plugin to show the query! This would still suffer from 
the the latest information doesn't match my current tree+config combination 
issue that gps raised; e.g. people building Aurora or Beta wouldn't find the 
query super useful.

We could do the whiteboard tag(s) in addition to a source-controlled document, 
and somewhere in the document add something like don't see your issue here? 
Try this - bugzilla query or wiki link or here

Thoughts?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Central location for tracking known broken build configurations (with bugs)

[Tim Abraldes]

  Possible compromise: have this info live in the tree as part of the
  in-tree docs under build/docs. You need build peer review to update
  those docs and they are versioned with the tree. That addresses my
  accuracy and versioning concerns.
 
  This sounds reasonable to me! The docs would always be up to date with the
  code being built, anyone experiencing an issue can look it up in a known
  location, anyone with knowledge about a particular issue can update the
  doc, and build peers don't have to spend their time keeping config rules
  constantly up to date! Assuming people are on board with this plan, how
  would we go about starting that doc?
 
 b76171a0d6ec and newer (currently inbound only) have a
 build/docs/supported-configurations.rst file documenting supported build
 configurations. I just filled it in with basics.
 
 Feel free to make obvious updates with NO BUG DONTBUILD (NPOTB) and
 no build peer review. Please at least get a pastebin/irc review from a
 build peer for anything too involved.
 
 If people have time to write patches to configure to enforce missing
 requirements, we'll happily review them.

The doc looks great! To further solve the issue of my build broke and I'm not 
sure what config-option caused it or how to fix my build, we could add a 
section like the following to the doc:



Known Issues


This section documents known issues that cause builds to fail.

Bug ID: 808932
Affected configs: Building B2G with --disable-optimize and --disable-jemalloc
Workarounds:

Bug ID: 899948
Affected configs: Building FX on VS(any) with --disable-optimize but not 
--enable-debug
Workarounds: --without-intl-api

Don't see your issue here? Try here - bugzilla query or wiki link or here



I'm not in love with the format - it seems like the list will not be very 
readable if there are 20+ or so items in it - maybe we could split the list up 
by platform or something? I'm also happy to just use this as a starting point 
and modify the format if/when it becomes an issue.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsRefPtr vs RefPtr

[Tim Abraldes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 The chromium IPC code is ours now, so we can mdify it as needed.
 Not sure about the Chromium sandbox code.

The Chromium sandbox code lives at security/sanbox in the tree.
AIUI, we wanted to be able to pull upstream changes easily so we've
avoided making modifications to it. It has its own copy of the
Chromium base libraries that we'd like to someday de-duplicate [1] -
I'm not sure if the type of changes we're talking about in this thread
would make that more difficult.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=925471
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTcmiJAAoJENMT71e+7HCHpo0QAIt1qWLpzz9sseC8aUZFMdXa
xfO361XDEeOzuaa0bjzuhwur/Yyit0mgB/BCmscJyRbYXirvwR4JitqqXFuwdWx2
OFgadjnyJpjup41vGycRRtEX1uuBEslX1tTXfSdAcK3lx5B1AbsY3SS+b5uByeP7
KIJUXDXGoA2yv+7ysUqhjeqDkYYcNekKz1EGtkrKH3nJm8zbBmBWsLkb6A4cy1RJ
SLTJuQv+58pa0Pl8Gv7VO0N4j9L46eWObiAtqVJGftKw4Oxne9UAdWVJPcO6tyKY
+288F1wJJQ7mtjv9R2INR10WE6T8cooDMHiksdPTPVJn+OmnMaKMtpKT+ZJDWZME
ikOAhKLNoZHR4dcGq/qHprc9TYaVYC4a9I8SR/41GbHGm7ogaP6MzS4LMzTVGr/q
4LojP4lRIyqgyYzLFumWJ/Zymq7ppDqJLezLfzDUTtP44MK9aV+DK9+/A078VgEX
E51q8jRDF3pc8x6joQ8yLLz6rAMGT3Eg3C6lQkXdPNNia1kf+uQ5QuSHMlIryjgI
ocpKDJT6MCWXTLW6k92d/GzMWWjOl/kaYghTbBFlbsX8SyiDCVrdeRNwevtMvyL+
d7y2a0YNoiYc9sMiNfBIdQ9rHOV9corYRMUcv4ZN/ZIsjfsKGmB/WcICDPnMarX1
PUU+uUBLfzs9Fron8nAc
=lv9x
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: People building and debugging Firefox on Windows wanted

[Tim Abraldes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Build took 41:02 with these options:
  ac_add_options --enable-chrome-format=flat
  ac_add_options --disable-optimize
  ac_add_options --enable-debug-symbols
  ac_add_options --disable-crashreporter
  ac_add_options --disable-updates
  ac_add_options --disable-tests
  ac_add_options --without-intl-api
  ac_add_options --enable-jemalloc

Builds took 37:12, 34:58 with these additional options:
  mk_add_options export COMPILE_PDB_FLAG=
  mk_add_options export HOST_PDB_FLAG=
  mk_add_options export MOZ_DEBUG_FLAGS=-Z7
  (removed ac_add_options --enable-debug-symbols)

That's a 9.3% - 14.8% improvement [0][1].

I noticed that PDB files were still generated; is that expected or did
I miss something in the configuration options? Also, I did run into an
issue where WinDbg wasn't able to show me source code for some
functions in xul.dll (which normally it should have been able to).
I'll keep investigating to see if that was a fluke or if there are
some STR I can post here.

[0]
https://www.wolframalpha.com/input/?i=1+-+%2837+minutes+12+seconds%29+%2F+%2841+minutes+2+seconds%29
[1]
https://www.wolframalpha.com/input/?i=%281+-+%2834+minutes+58+seconds%29+%2F+%2841+minutes+2+seconds%29%29


On 4/24/2014 1:14 AM, Mike Hommey wrote:
 Hi,
 
 While working on shared compilation cache for windows, I noticed I
 could get a 20% build time improvement with the following in
 .mozconfig:
 
 mk_add_options export COMPILE_PDB_FLAG= mk_add_options export
 HOST_PDB_FLAG= mk_add_options export MOZ_DEBUG_FLAGS=-Z7
 
 (the downside is a 40% disk space increase of the objdir)
 
 This is what is currently used on try, and as far as testing goes,
 it is good enough for breakpad symbols to have the right data so
 that crashes in tests can be handled correctly.
 
 I'm looking for people to test this setup more thoroughly and see
 if it affects their debugging. If that works out well, we may make
 it the default.
 
 Cheers,
 
 Mike
 
 PS: please report what build time difference that makes for you,
 too. ___ dev-platform
 mailing list dev-platform@lists.mozilla.org 
 https://lists.mozilla.org/listinfo/dev-platform
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTdA5fAAoJENMT71e+7HCHlmAQAIKWzlGdUBe/8ZGZN4GgpQI5
IM4Iu8ZvBx+/ltbg9FWD8qwQaDoDvvn90+N3g1d6GL6c9qofkzXAhGJT4rQBdmSo
Ky2KxXHwP+20oLufE2zCKVL/w5CYg4sw0E8dsbTAp6A90ZmO72T89wa0S132b9IP
2T4xbJVFND8hecMjQi2eWnqpSEmhg2EXpVw0r4C3LDsCdcUswgV6YdYpcVqjWD2u
+JIQvYTSHxxdeF/iMQFU2lA10Bm81Q1w5wHJHSFXpRDtrrDtiu6w8qNqsZ0Ti2AG
JMge5Pbb0BJEF/N0lCSQjK4gGnuFda/h6ChbMIspnBJ3C5FIHlOcCOcSob85tyRC
A2NdElM6kKOQxODg6dSpZNkJ8GFfUSypl31u4EfuRiIAdeRbz8Y20HjsRMzLc0n+
QHlVVrrnh5fQb9sNDdjwZf5Qs4tDMXgpWedCcWKneLarp5oibh+l8goxsAC2cYVa
byGAgUtZUqtKqBYITtakAvVlBjgjJpnHs32E/3P56aHNiWTfcsZ1jvbtom1aZiAj
2GynunSIK5MNZ2YKJ6c/cKdQ6sCd/mpWlb0mzMm8fIJgNfqU8TRpg+F9IE1tr15M
JbyQSmxqXW4Ds6KuSvxbO8QdN5lf5SLjaS24wMiihyoZknZfe/K2ijnwsM+DWazm
9mkRag+fABzCJvmW8sDV
=Hrww
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

Jonathan Kew wrote:
 When I click a Google search result (for example), I can see -- thanks
 to the status overlay that shows the URLs being requested -- that it's
 redirecting me via a Google URL that is presumably being used to track
 me. So although this is hardly an optimal UI, at least I get a clue that
 the site is doing something more than simply giving me a link that I
 follow, and if I want to avoid telling Google which results I'm
 clicking, I need to somehow work around this.

Google and DuckDuckGo are hiding these, when hovering a search result
link I don't see that the browser will request a different page first
and redirect me afterwards. I think for the average user this is hardly
different from not seeing any hint at all.

 If this is replaced by the use of a ping on those search results, then
 (AFAICT) there will no longer be *any* clue to alert me as a user to the
 fact that the site is monitoring which result I click on. This allows
 pages to more easily track me without ever bringing it to my attention.
 So I do think there's a disadvantage here.

The argument we make it easier to track seems valid at first but we
can't even prevent that right now. If sites want to and will do that
anyway we should at least provide a way that has less disadvantages for
the user.

- Tim


-- 
Tim Taubert
Engineering Manager, Firefox
@ttaubert
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

L. David Baron wrote:
 We need to be careful to design the preferences we expose to the
 user in ways that make sense even if sites don't want to honor those
 preferences.  It's not clear to me that it makes sense to have a
 preference to disable one particular tracking feature when sites can
 do that sort of tracking in many other ways that aren't controlled
 by the preference.

That's a great point. I think it really might make sense to remove the
preferences altogether as the number of pings per link limit and the
same hosts requirement can actually be worked around quite easily and
would make websites just fall back to the same bad behavior that we
currently have. Ensuring this feature works as expected would surely
drive adoption a lot better.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

Curtis Koenig wrote:
 Given our stance on privacy[1] and commitment to Real Choices, Sensible 
 Settings and User Control; I don’t believe removing the users ability to 
 control this preference would be a positive move. David’s point is more 
 correct in that we need to be careful as to how the preference is exposed. We 
 could also do something very innovative in this case like what is done with 
 do not track. We could default to allowing all requests (which would honor 
 the spec) but allow the users to change the pref to 2 other states. One being 
 only allow pings from the sites I specify and the final one being don’t allow 
 any at all. With accompanying text that explains the tradeoffs/benefits/pain 
 of each setting. This would help us both keep inline with the goal of 
 Hyperlink Auditing and balance our stance on privacy.

I am all for real choice and keeping the user in control but offering
these preferences does nothing but pretend to protect users and their
privacy. If there is a chance the user might have turned it off without
the site noticing then websites will just keep on doing what they do
currently. Without any chance for the user to intervene or limit, and
without a way to notice this is happening. And with all the current
performance impacts.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

Curtis Koenig wrote:
 Would this be disabled in Private Browsing? If not that might be perceived as 
 negating one of the reasons users have for using that particular feature.

Are sync XHRs and HTTP redirects disabled in private browsing? :)

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

Curtis Koenig wrote:
 Assuming I am understanding this correctly, it appears from this doc 
 https://developer.mozilla.org/en-US/docs/Supporting_per-window_private_browsing
  that they maybe disabled in some instances of private browsing given changes 
 in Fx 20.

The only thing I can see here is that I can force single
requests/channels into private mode, which means they won't persist
cookies, sessionStorage, cache entries, etc. All other means of tracking
navigation by rewriting links before clicking and then redirecting, or
firing a sync XHR do still work and probably can't be disabled because
they would break the web.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Hyperlink Auditing (a ping)

[Tim Taubert]

Jonathan Kew wrote:
 On 16/5/14 14:37, Kyle Huey wrote:
 On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig curt...@mozilla.com
 The point being made is that the preference is not a real choice.  If
 you disable this feature you can still be tracked in the exact same
 way by methods that exist today and are not covered by the preference.
 
 Yes; but the methods being used by at (least some major) sites are
 visible to the user, which makes them less insidious than an
 invisible-by-design tracking feature.

I doubt that the common user will notice any of these tracking measures.
Even I wouldn't notice if I don't pay attention or the network would not
sometimes be slow to load.

 If we implement a ping, and make it on-by-default (but with a user
 preference to turn it off), we can reasonably expect sites to use this
 as their tracking method in place of redirects, etc. And if they hten
 detect (can they?) that the user has turned off pings and fall back to
 other methods to track the user - who by disabling it has expressed a
 desire not to be tracked - this puts them in much the same category as
 those who decide to stop honoring Do Not Track.

Web pages can't detect whether pings are actually sent, they know when
those arrive at their endpoints. Thus if a website is concerned about
Firefox users having turned this feature off they might just keep it the
way it currently is and thus be sure it works for every user.

 We can't force sites to honor DNT, and we can't prevent them working
 around user-disabled a ping. But in both cases we can and should (IMO)
 provide a simple means for the user to express a wish about tracking.
 Respectable sites will interoperate nicely with it; those that decide to
 circumvent it should be publicly shamed.

Using DNT is a flawed comparison, DNT is very much only about letting
websites know without the ability to prevent any of that tracking.
Websites can't tell whether a ping is enabled and thus there is no
real point in shaming any of them when we can't even prove they're not
using a ping because some users might have turned it off.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

sandboxbroker.dll will soon build by default on Windows

[Tim Abraldes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

To build Firefox with support for process sandboxing, you currently
pass the --enable-content-sandbox flag. On Windows, using the
--enable-content-sandbox flag causes an extra DLL to be built -
sandboxbroker.dll - which is responsible for providing all of our
process sandboxing functionality.

In bug 985252 [1] and friends, we're working on implementing process
sandboxing for processes other than content processes (in this case,
GMP plugin processes specifically). This means that we're de-coupling
--enable-content-sandbox from the building of sandboxbroker.dll; the
DLL will be built in all Windows Firefox builds regardless of whether
--enable-content-sandbox is specified, and it will be included in
the Firefox installer. This change should only affect Windows builds
and it looks like the installer size increase is about 61K or 0.18%.

Let me know if there are concerns regarding this change.

Thanks!
  Tim

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=985252
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJThOTzAAoJENMT71e+7HCHrkkP/1qR4wJyz/08FyGN0YFJXOer
OTHbsm//IrSHuAV39VdA4mVhY2IF0AmUyslwjYxq+LvTpfIMOB9QCqsSVaW0MvCH
lAlb/AJw1SZobysb8SHb8qgfkVHxcbbVCGfv6s3lGpoCtmf5ShoDNTGyXpN0d4w7
L6qCGdBt8nh3PtwqpPd2iBZHf90kxjTH08DXWrRkROH38mha05aWUgJvKSgRz1f4
SxiuaPNzB+TzUWAGVzF/d9CUSd//aE4hIFml4sJak2sHDlnk27Lp/QNDHMBE7OBc
hZ+wCnRyfv4r46UoXL3ybByPN5AvL5Hj8Wx03EJ3ilZoasV7LkxCu8WToVAyYFc5
4jRhmIHYKPcdrUH6aO9Ru5Nj1MRGPxCgxmWsHex8hPFZhkt7PuRLrPtaFqOE1irH
gyRJrUI1DGbJJCh434yfW9CCMiYvCngiJM94dEWcgirWei/8CvtMpUyDmPuDrhlg
Y0qumSLQ5XQEM6eDAI3TN/tqFGt4nHs2HpN68fwYr9Evhk+wlAkw6gOErMHC/1+d
M7UIRfTzTQY3Vk033et0wE3vq42d+S/AVrT2wcbh3IpQKhdaVfsm8cpClsXsFHt6
L4Y4qWgtO9uQIIUIMQ5JEy3poSUoiWadahOXUZaRBh5cxpxveWuBMY/vbpzAnZTY
62TmAj5Scn/hFU8vEk9H
=BcVL
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Session Restore (sessionstore)

[Tim Taubert]

Tobias Besemer wrote:
 Am Donnerstag, 26. Juni 2014 17:33:22 UTC+2 schrieb Tobias Besemer:
 OK, I was redirected in bug 810932 to this group for discussions about how to 
 change/improve the sessionstore ...

Thanks for moving the discussion here.

 ... so I now want to start the discussion with my idea, that ss.js should 
 forget the most things when Firefox gets closed manual by the user, 
 originally posted here: 
 https://bugzilla.mozilla.org/show_bug.cgi?id=810932#c22

To properly set the stage for this discussion, why exactly do you want
this? Where do you see the problem with a big sessionstore.js file?
What problems are you currently hitting that you think will be fixed by
downsizing sessionstore.js?

 So what do others / the developers think about this ???

I do agree with the two other posts, I don't want any of my data gone
automatically. Some weeks ago we landed a patch[1] that automatically
purges closed/windows and tabs that are older than two weeks. I still am
not a big fan of that but it seemed worth trying without causing too
much harm. Turns out that this patch doesn't actually achieve[2] what it
should.

As said above I think it would be great to get some basic questions
answered before we talk about purging data. Maybe there are other ways
to mitigate the problems you're seeing. We shouldn't talk about a
specific solution before stating the problem.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=989393
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=989393#c20

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Session Restore (sessionstore)

[Tim Taubert]

Tobias Besemer wrote:
 What problems are you currently hitting that you think will be fixed by
 downsizing sessionstore.js?
 I have ~4-8 GB I/O because of ss on a 8h day. Please look at the bugs you 
 have commented before.

I looked at those bugs and they don't have better problem descriptions
either unfortunately.

Why is the amount of I/O a problem for you exactly? We unfortunately do
not have a journaled storage but we are working towards it. I doubt that
removing data on Firefox shutdown would solve your problem as most of
the writes happen when Firefox is running.

Is it just the sheer amount of I/O that you dislike? If yes, why? Have
you taken a look at all the other I/O caused by places, cache, etc. and
how that compares?

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Session Restore (sessionstore)

[Tim Taubert]

Tobias Besemer wrote:
 The ss is necessary, when e.g. a user editing a large text in a wiki, haven't 
 saved that text yet, and closes this page as a mistake. So he can go back / 
 undo close and still have his un-saved text ...

Yes, this was the reason why sessionstore was introduced years ago.
Today sessionstore provides much more than just crash recovery and a lot
of people rely on it.

 IMHO this scenario is so unlikely, that is makes no scene, to keep a lot of 
 data in the ss for each user by a manual close with the default settings.

You are evading my questions and still haven't answered why the amount
of I/O you say you're seeing is a problem for you. Instead of
re-iterating your proposal and what you think we should be doing it
would be great if you could tell us why the current behavior is a
problem for you.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Session Restore (sessionstore)

[Tim Taubert]

Tobias Besemer wrote:
 The amount of I/O is always a problem! E.g. for Notebooks in battery use.

Yes, of course. That is a known problem and we're working on it by
increasing the write interval when running on battery and working
towards a journaled storage.

As I said before, cleaning sessionstore data on write will not buy you
much as we write a lot when Firefox is running. This is the problem
we're tackling in the long run and band-aid fixes won't help here.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Session Restore (sessionstore)

[Tim Taubert]

Tobias Besemer wrote:
 Am Samstag, 28. Juni 2014 14:25:35 UTC+2 schrieb Tim Taubert:
 Tobias Besemer wrote:

 The amount of I/O is always a problem! E.g. for Notebooks in battery use.
 Yes, of course. That is a known problem and we're working on it by
 increasing the write interval when running on battery and working
 towards a journaled storage.

 As I said before, cleaning sessionstore data on write will not buy you
 much as we write a lot when Firefox is running. This is the problem
 we're tackling in the long run and band-aid fixes won't help here.
 
 It is not just a question of battery!
 Too much writing accesses also harms the life-time of HDs or SSDs!

Yup, that's why we're working on it. Clearing data on quit won't get us
there as data accumulates while browsing again and probably 90+% of the
I/O happens while Firefox is running.

 I also asked before (on the bugs) about more informations to the journaled 
 storage ...

Great, but as I said we are working towards it. We don't know any
details yet.

 If it is - like I think - a lot of small files, I don't like it!

Ok.

 A lot of small files wast a lot of un-used bytes on the storage and brings a 
 big fragmentation to it! This significantly slows down a system!

File systems have a lot of counter measures nowadays so that might not
be as relevant anymore but I don't know for sure. We haven't decided on
any journaled storage yet and we will be looking into multiple options,
writing our own storage or taking an existing one. Performance and I/O
will of course be important factors.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: WebCrypto API

[Tim Taubert]

As of September we intend to enable the WebCrypto API by default on all
platforms. It has been developed behind the dom.webcrypto.enabled
preference.

Tracking bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=865789

Spec:
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
(A CR is planned soon, only smaller changes to the spec lately.)

Reasoning:
The implementation of the WebCrypto API has made lots of progress in
Firefox 33+34. We added most of the basic functionality and algorithms,
and should be mostly spec compliant.

Chromium has had the WebCrypto API enabled by default since Crome 37,
which was released in late June 2014. Their implementation supports a
subset of the algorithms that we do, and has roughly the same level of
spec compliance. We expect the two implementations to be mostly
interoperable as-is, with some fine points being ironed out as the spec
is finalized.

We thus propose to enable the WebCrypto API by default for all platforms
to get some more feedback from developers and give them the opportunity
to use new functionality.

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebCrypto API

[Tim Taubert]

Ehsan Akhgari wrote:
 Can you please clarify what are the areas that we don't fully adhere to
 the spec?  Do we expect the fixes to those and potentially new spec
 issues in the future to break backwards compatibility?

KeyAlgorithms were recently changed to dictionaries (from interfaces)
and we did not get around to change that yet. Richard Barnes has a patch
almost ready in bug 1037892 [1] though.

We didn't have to change tests to make them work with KeyAlgorithm
dictionaries so that change would not break existing code. We would
probably aim to land it before enabling WebCrypto by default anyway.

Other parts we're missing is import/export for some formats (e.g. PKCS8
for ECDH/DH) and we're missing a few algorithms completely. We only need
more time to implement those but that wouldn't break any existing code
either.

- Tim

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1037892


 Thanks!
 Ehsan
 
 On 2014-09-03, 1:36 PM, Tim Taubert wrote:
 As of September we intend to enable the WebCrypto API by default on all
 platforms. It has been developed behind the dom.webcrypto.enabled
 preference.

 Tracking bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=865789

 Spec:
 https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
 (A CR is planned soon, only smaller changes to the spec lately.)

 Reasoning:
 The implementation of the WebCrypto API has made lots of progress in
 Firefox 33+34. We added most of the basic functionality and algorithms,
 and should be mostly spec compliant.

 Chromium has had the WebCrypto API enabled by default since Crome 37,
 which was released in late June 2014. Their implementation supports a
 subset of the algorithms that we do, and has roughly the same level of
 spec compliance. We expect the two implementations to be mostly
 interoperable as-is, with some fine points being ironed out as the spec
 is finalized.

 We thus propose to enable the WebCrypto API by default for all platforms
 to get some more feedback from developers and give them the opportunity
 to use new functionality.

 - Tim
 ___
 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 ship: WebCrypto API

[Tim Taubert]

helpcrypto helpcrypto wrote:
 I'll love to know if Mozilla/Firefox is going to provide something (even
 out-of-standard) to make possible using PKCS#11/NSS with Webcrypto.

The WebCrypto API basically exposes PKCS#11/NSS functionality with a DOM
API.

 This will fill the gap that currently exist with hardware token support

Not sure what exactly what you are referring to here but I don't know of
any current plans to extend the WebCrypto API beyond what the spec says.

- Tim

 (which, is going to be discussed nexr 10th September)
 Regards.
 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebCrypto API

[Tim Taubert]

Dirkjan Ochtman wrote:
 Is there a list of algorithms we support somewhere, particularly the
 ones we share with Chromium? IIRC the supported algorithms is where
 the real interop problems are expected to be. (I quickly searched MDN,
 but that didn't turn up anything useful.)

Richard Barnes made a nice list of algorithms [1] we support and the
Firefox version they were introduced. A similar list [2] exists for
Chromium, but I can't tell how up-to-date that is. Judging from their
list of tests [3] this seems to indeed list of all of the available
algorithms.

- Tim

[1]
https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkEusp=sharing#gid=1
[2]
https://docs.google.com/document/d/184AgXzLAoUjQjrtNdbimceyXVYzrn3tGpf3xQGCN10g/edit?pli=1
[3]
https://chromium.googlesource.com/chromium/blink/+/master/LayoutTests/crypto/

 Cheers,
 
 Dirkjan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: WebCrypto API

[Tim Taubert]

Anne van Kesteren wrote:
 In Chromium the methods only work on authenticated origins. What is
 our story?

Completely agree with Ehsan and Henri. I don't know of any plans to even
consider doing that and we currently expose the WebCrypto API to
unauthenticated origins as well.

 Is the non-overlap of algorithms documented on MDN?

We currently have no documentation for the WebCrypto API other than for
crypto.getRandomValues(). It should certainly be documented on MDN and
we could provide a list of algorithms we support. Not sure whether we
would want to do that for Chromium's supported algorithms as well?

- Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

SVG in our source code

[Tim Nguyen]

The number of SVGs in our source code has been growing quite fast during the 
last months and unfortunately a lot of SVGs entered our code without being 
cleaned up.

Making sure new SVGs are clean should be part of the review process, because 
SVG is code, and code should be clean.

So, I propose making guidelines for SVGs in our source code that need to be 
respected in order to get the SVG shipped. Here's a draft for possible 
guidelines [0] based on stuff seen in [1], where all our SVGs were cleaned up. 
These guidelines should be added on MDN so developers can have a reference.

Thoughts ?

[0] : https://etherpad.mozilla.org/svg-guidelines
[1] : https://bugzilla.mozilla.org/show_bug.cgi?id=1160771

Tim Nguyen [:ntim]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fingerprinting of battery status?

[Tim Taubert]

Ben Kelly wrote:
 Can we just reduce the accuracy of the API?  Only give battery level at
 certain broad breakpoints?

The authors of the cited paper [1] filed a bug report and we fixed that
for 38 [2].

- Tim


[1] http://eprint.iacr.org/2015/616.pdf
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1124127


 On Tue, Aug 4, 2015 at 11:02 AM, Chris Hofmann chofm...@mozilla.com wrote:
 
 I've seen a lot of GPS related tracking apps that use a lot of power
 putting up warnings to users
 that it might be time to go to low power mode and shut down the GPS if
 you'll need it
 later for navigating a critical pathway later in your journey.

 -chofmann

 On Mon, Aug 3, 2015 at 7:49 PM, Katelyn Gadd k...@luminance.org wrote:

 Games for mobile phones, handheld devices, and laptops often show a
 battery indicator and/or a clock in the corner of the screen while
 running in fullscreen mode. That's the only good reason I can think of
 off-hand.

 On 3 August 2015 at 12:55, Chris Peterson cpeter...@mozilla.com wrote:
 What is a legitimate use case for a web page to know my battery status?
 Battery level and time remaining can be used to fingerprint users.

 A mobile webapp might use battery level to throttle its activity, but
 that
 could be something the OS handles by pausing or throttling apps
 directly
 or
 broadcasting app lifecycle events. I can't think of a good reason why a
 web
 page in a browser, especially on a desktop OS, needs to know anything
 about
 my battery.


 http://www.theguardian.com/technology/2015/aug/03/privacy-smartphones-battery-life
 http://eprint.iacr.org/2015/616.pdf


 chris
 ___
 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

 ___
 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

Intent to implement: HTML5 element

[Tim Nguyen]

*Summary*:
The *HTML  element* represents a dialog box or other interactive
component, such as an inspector or window.
It will initially be implemented behind a pref.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640

*Link to standard*: https://html.spec.whatwg.org/multipage/forms.html#the-
dialog-element

*Platform coverage*: All

*Estimated or target release*: Firefox 54

*Preference behind which this will be implemented*:
dom.dialog_element.enabled

*DevTools bug*: None yet, although I'm not sure how we can make DevTools
more useful here ?

*Do other browser engines implement this?*
Shipped: Chrome (since version 37)
Considering: Edge ( http://status.modern.ie/dialogelementformodals )

*Tests*:
https://github.com/w3c/web-platform-tests/blob/master/
html/dom/interfaces.html#L1835
https://github.com/w3c/web-platform-tests/tree/master/
html/semantics/interactive-elements/the-dialog-element
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

[Tim Nguyen]

Non-modal dialogs should just work fine in a chrome window (the dialog
would just be like a centered absolute positioned div). As for modal
dialogs (eg. dialogs that makes everything else inert), it would depend on
whether the current top-layer implementation works within a chrome window
and I don't think it is the case currently. So, I don't expect modal
dialogs to work within the chrome window (at least not without some extra
platform work). Xidorn might know better though.

As for how modal dialogs *should* behave in a chrome window, I would expect
it to be the same as for web content, i.e. it modal dialogs should make all
UI elements except the current dialog inert.

Tim


On Fri, Dec 23, 2016 at 12:33 AM, Justin Dolske <dol...@mozilla.com> wrote:

> What's the expected experience if chrome code uses this feature? (In a
> chrome window, interaction with a content window isn't the thing I'm
> wondering about.)
>
> Justin
>
> On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen <ntim...@gmail.com> wrote:
>
>> *Summary*:
>> The *HTML  element* represents a dialog box or other interactive
>> component, such as an inspector or window.
>> It will initially be implemented behind a pref.
>>
>> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>>
>> *Link to standard*: https://html.spec.whatwg.org/m
>> ultipage/forms.html#the-
>> dialog-element
>> <https://html.spec.whatwg.org/multipage/forms.html#the-dialog-element>
>>
>> *Platform coverage*: All
>>
>> *Estimated or target release*: Firefox 54
>>
>> *Preference behind which this will be implemented*:
>> dom.dialog_element.enabled
>>
>> *DevTools bug*: None yet, although I'm not sure how we can make DevTools
>> more useful here ?
>>
>> *Do other browser engines implement this?*
>> Shipped: Chrome (since version 37)
>> Considering: Edge ( http://status.modern.ie/dialogelementformodals )
>>
>> *Tests*:
>> https://github.com/w3c/web-platform-tests/blob/master/
>> html/dom/interfaces.html#L1835
>> https://github.com/w3c/web-platform-tests/tree/master/
>> html/semantics/interactive-elements/the-dialog-element
>> ___
>> 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

Intent to Remove: Insecure use of WebCrypto

[Tim Taubert]

Summary: The WebCrypto spec [1] states that window.crypto.subtle
should only be usable from a secure origin (i.e. on a domain being
served over HTTPS). Currently Gecko's implementation works on insecure
origins (i.e. sites served over unencrypted HTTP). To bring our
implementation in line with the spec, we're going to remove access to
crypto.subtle on non-secure origins.

Sites using the WebCrypto API's crypto.subtle interface on a
non-secure origin should switch to HTTPS as soon as possible.

Chrome too is planning to remove access to crypto.subtle on non-secure
origins [2]. Edge seems positive about implementing those restrictions
as well [3].

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140

Standard: https://w3c.github.io/webcrypto/Overview.html

Platform coverage: This will affect Windows, MacOS, Linux, and Android.

Estimated target date: This could land as early as Firefox 56, but
should in Firefox 57. We probably want to coordinate with Chrome, they
seem as ready as we are.

Our telemetry [4] indicates that about 9% of crypto.subtle use is
still on insecure origins. This was at around 1-2% - that's not the
percentage of all users, but only of those that visit pages that use
crypto.subtle - but became inflated around two weeks after we started
measuring. The blink-dev thread [2] has a good summary and indicates
that this is caused by Twitter launching AMP support serving from
origins which may be insecure. AMP has a fallback that is lazy-loaded
in case crypto.subtle isn't available, so no one's Twitter would break
when we ship this.


[1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
[2] 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZD3NWqkk-bo/discussion
[3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
[4] https://mzl.la/2ttx8aV
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Leakage of amount of storage used

[Tim Huang]

On Thu, Jun 29, 2017 at 11:08 AM, Anne van Kesteren <ann...@annevk.nl>
wrote:

> Persistent storage gets the global quota. We also expose the local
> quota (that of the origin). That means that by filling up space you
> can determine how much space all other origins take up together.
>
> Persistent storage for an origin is user opt-in through a dialog (and
> maybe "add to homescreen/new tab" at some point in the future).
>
> Presumably we already have this leak with a proprietary extension to
> IndexedDB that enables persistent storage (though slightly different
> in nature; it's not bound by the global quota but by disk space).
>
> This data could be used for fingerprinting.
>
> Is this acceptable or should we seek to actively avoid it somehow?
> E.g., by limiting persistent storage to an amount less than the global
> quota.
>
>
If this is the problem that was described in
https://github.com/whatwg/storage/issues/31

Yes, we are trying to solve this problem right now. There is a bug, Bug
1290481 <https://bugzilla.mozilla.org/show_bug.cgi?id=1290481>, has been
opened for tackling this issue.


> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
Tim Huang
Mozilla Taiwan
email:tihu...@mozilla.com
phone:+886-2-8786-1100#402
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: moz*Frames attributes of HTMLVideoElement

[Tim Huang]

I intent to unship the support of moz*Frames of HTMLVideoElement including
* HTMLVideoElement.mozParsedFrames
* HTMLVideoElement.mozDecodedFrames
* HTMLVideoElement.mozPresentedFrames
* HTMLVideoElement.mozPaintedFrames
* HTMLVideoElement.mozFrameDelay
in Bug 1379050 [1].

The reason of this is threefold.
1. They are non-standard API and Gecko is the only one implements them.
2. The VideoPlaybackQuality[2] provides a similar feature.
3. There is a potential risk of browser fingerprinting[3] for these
APIs.

For these reasons, we should remove them.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1379050
[2] https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality
[3] https://trac.torproject.org/projects/tor/ticket/15757

-- 
Tim Huang
Mozilla Taiwan
email:tihu...@mozilla.com
phone:+886-2-8786-1100#402
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

[Tim Huang]

On Fri, Jul 7, 2017 at 11:54 AM, Jet Villegas <jville...@mozilla.com> wrote:

> What do we expect to break?


I can see that video quality auto adjusment which is based on these APIs
will become malfunction. But, I don't know is this a real use case that a
website implement video quality adjusment based on these APIs.


> Who's out there using these APIs now?
>

There are some addons using these APIs to report media statistics. For our
internal use, there are only some test code using them. And I think the
VideoPlaybackQuality can be used to replace them since it provides a
similar feature.


> Thanks,
>
> --Jet
>
>
> On Thu, Jul 6, 2017 at 8:21 PM, Tim Huang <tihu...@mozilla.com> wrote:
> > I intent to unship the support of moz*Frames of HTMLVideoElement
> including
> > * HTMLVideoElement.mozParsedFrames
> > * HTMLVideoElement.mozDecodedFrames
> > * HTMLVideoElement.mozPresentedFrames
> > * HTMLVideoElement.mozPaintedFrames
> > * HTMLVideoElement.mozFrameDelay
> > in Bug 1379050 [1].
> >
> > The reason of this is threefold.
> > 1. They are non-standard API and Gecko is the only one implements
> them.
> > 2. The VideoPlaybackQuality[2] provides a similar feature.
> > 3. There is a potential risk of browser fingerprinting[3] for these
> > APIs.
> >
> > For these reasons, we should remove them.
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1379050
> > [2] https://developer.mozilla.org/en-US/docs/Web/API/
> VideoPlaybackQuality
> > [3] https://trac.torproject.org/projects/tor/ticket/15757
> >
> > --
> > Tim Huang
> > Mozilla Taiwan
> > email:tihu...@mozilla.com
> > phone:+886-2-8786-1100#402
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>



-- 
Tim Huang
Mozilla Taiwan
email:tihu...@mozilla.com
phone:+886-2-8786-1100#402
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Remove: Insecure use of WebCrypto

[Tim Taubert]

On Fri, Jul 28, 2017 at 10:15 PM, Jonathan Kingston <j...@mozilla.com> wrote:
> Hey Tim,
>
> The only questions I have about this our are difference in implementation
> over Chrome the more we increase the use of [SecureContext] the greater risk
> we put on compat bugs.

Good news, the implementation difference was just removed by Kate in
bug 1410364.

Let's move forward with the proposal for Firefox 59.

> Our implementation differs in that we actually abide to the specification on
> window.opener insecure contexts making the openee insecure. This may for
> example cause breakage on payment sites that want to use crypto.
>
> Perhaps we should shift to using SecureContextIfOpenerIgnored instead; at
> least for the time being?
>
> The difference is somewhat a technicality anyway as the inverse isn't true a
> SecureContext that opens an !SecureContext is not then treated as insecure
> despite the risk being pretty much the same.
>
> On Thu, Jul 20, 2017 at 3:47 PM, Tim Taubert <ttaub...@mozilla.com> wrote:
>>
>> Summary: The WebCrypto spec [1] states that window.crypto.subtle
>> should only be usable from a secure origin (i.e. on a domain being
>> served over HTTPS). Currently Gecko's implementation works on insecure
>> origins (i.e. sites served over unencrypted HTTP). To bring our
>> implementation in line with the spec, we're going to remove access to
>> crypto.subtle on non-secure origins.
>>
>> Sites using the WebCrypto API's crypto.subtle interface on a
>> non-secure origin should switch to HTTPS as soon as possible.
>>
>> Chrome too is planning to remove access to crypto.subtle on non-secure
>> origins [2]. Edge seems positive about implementing those restrictions
>> as well [3].
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140
>>
>> Standard: https://w3c.github.io/webcrypto/Overview.html
>>
>> Platform coverage: This will affect Windows, MacOS, Linux, and Android.
>>
>> Estimated target date: This could land as early as Firefox 56, but
>> should in Firefox 57. We probably want to coordinate with Chrome, they
>> seem as ready as we are.
>>
>> Our telemetry [4] indicates that about 9% of crypto.subtle use is
>> still on insecure origins. This was at around 1-2% - that's not the
>> percentage of all users, but only of those that visit pages that use
>> crypto.subtle - but became inflated around two weeks after we started
>> measuring. The blink-dev thread [2] has a good summary and indicates
>> that this is caused by Twitter launching AMP support serving from
>> origins which may be insecure. AMP has a fallback that is lazy-loaded
>> in case crypto.subtle isn't available, so no one's Twitter would break
>> when we ship this.
>>
>>
>> [1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
>> [2]
>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZD3NWqkk-bo/discussion
>> [3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
>> [4] https://mzl.la/2ttx8aV
>> ___
>> 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: Pulsebot in #developers

[Tim Taubert]

+1

A separate channel sounds like a great idea. And it will help
dealing with two very different kinds of information.

On Sat, Nov 4, 2017 at 5:38 PM, Simon Sapin  wrote:
> On 04/11/17 17:21, Zibi Braniecki wrote:
>>
>> +1
>>
>> The only thing I'd like to see from pulsebot on developers is:
>>
>> "26 commits have been merged from autoland into mozilla-central.
>> List:http://...;
>
>
> Even that would probably be still be high traffic. A separate channel would
> allow interested people to opt-in.
>
> --
> Simon Sapin
>
> ___
> 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

Intent to implement: Suppress exception/error reporting when loading an unknown external protocol

[Tim Huang]

Summary: Gecko will report an error when loading an unknown external
protocol (by firing an NS_ERROR_UNKNOWN_PROTOCOL event). This could be a
privacy threat because the behavior allows websites to enumerate external
protocols of users’ platforms, which is a fingerprinting issue. To address
this problem, we propose to suppress the error when loading an unknown
external protocol.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=680300

Link to standard: No formal specification for this. In the HTML standard
[1], there is one small paragraph describing how to handle external
protocols. However, it doesn’t define what we should do for unknown
external protocols.

Platform coverage: All platforms

Estimated or target release: Firefox 63

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

If allowed, does it preserve the current invariants in terms of what
sandboxed iframes can do? I believe so.

DevTools bug: None

Do other browser engines implement this?

I tested and verified on Chrome, Edge, and Safari. None of them would
report errors when loading unknown external protocols.

Tests: We will add a Mochitest test for this.

[1]
https://html.spec.whatwg.org/multipage/browsing-the-web.html#hand-off-to-external-software


--

Tim Huang

Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Intent to change] display: -moz-box elements will no longer be forced to display: block (browser chrome only)

[Tim Nguyen]

Hi everyone,

We plan to soon land a change behind a pref [0] where we’ll stop
“blockifiying” elements with `display: -moz-box`. Before this change,
elements with `display: -moz-box` are forced to `display: block` when the
element:

  1. Is a child of a CSS grid or CSS flex container
  2. Has position absolute or fixed
  3. Is floated

This change will land behind a preference initially
(layout.css.xul-box-display-values.survive-blockification.enabled). There
are still some visual issues in the browser chrome with elements that rely
on the blockification behavior, and we plan to fix those by explicitly
setting `display: block`. Once we resolve these issues, we expect to remove
the pref and change the default behavior.

If you’re writing CSS that relies on the element being forced to `display:
block`, you’ll now need to explicitly set the display value in your CSS.
One thing to be careful with is the CSS specificity of the new display rule
that you’re adding, which might override an existing display rule.

The reason we’re making this change is to allow us to convert remaining XUL
grids to CSS grid layout [1], where the blockification of the grid items
breaks their appearance. We believe it will also make migration of other
XUL layouts to CSS easier. In particular, we think we can replace XUL deck
layout [2] and XUL stack layout [3] with a single area CSS grid layout. And
we think this will allow us to more incrementally replace XUL flexbox with
CSS flexbox (since migrating an element to the latter won’t break its
children).

Please reach out if you have questions or concerns about this change.

Cheers,
Tim

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1580012
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1520625
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1559192
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1576946
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: nsStackFrame aka. `display: -moz-stack` and related features

[Tim Nguyen]

Hi folks,

I’m planning to remove nsStackFrame in bug 1576946 [0]. This is part of a
larger effort to make the browser stop using XUL layouts and align on more
standard CSS layouts such as CSS grid or flexbox instead. The removal is
targeted for Firefox 72.

The removal includes these two non web-exposed features:
- `display: -moz-stack` and the `-moz-stack-sizing` property
- support for XUL absolute positioning attributes
(left/top/bottom/right/start/end XUL attributes), that only worked in
display: -moz-stack contexts

Note that the  element is not going away. It will instead be
implemented using a single-area CSS grid, so those usages won’t need to be
rewritten. However, if you were planning to use XUL absolute positioning
attributes, you’ll need to look into alternatives:
- `align-self: start` or `align-self: end` can be used to position the
element on the vertical axis if you were using `top="0"` or `bottom="0"`
- `justify-self: start` or `justify-self: end` can be used to position the
element on the horizontal axis if you were using `start="0"` or `end="0"`
- If you were using non-zero values in the attributes and the element is
using `display: block;` or a non-XUL block-level display value, you can use
CSS absolute positioning instead.
- If you were using non-zero values in the attributes with a XUL display
value, you can use a combination of `margin` and
`justify-self`/`align-self`, see this code change [1] as a reference.

Regarding `-moz-stack-sizing`, this property was used to determine whether
a certain element would influence the size of its parent. The current
usages in mozilla-central were only used for children of  [2] and
those usages didn’t seem to change visually with the new CSS grid-based
implementation of  which ignores the `-moz-stack-sizing` property,
so it made sense to remove it.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1576946
[1]: https://i.imgur.com/8hUDUDS.png
[2]:
https://searchfox.org/mozilla-central/search?q=-moz-stack-sizing=false=false=

Cheers,
Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: CSS conic-gradient

[Tim Nguyen]

Summary: CSS conic-gradients allow developers to specify gradients that
start from a certain angle where color stops are placed around the
circumference of a circle centered around a specified point.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=conic-gradients

Standard: https://drafts.csswg.org/css-images-4/#conic-gradients

Target Release: 75-76

Platform coverage: All, initially WebRender only (though it shouldn't be
long until it's implemented for other backends)

Preference behind which this will be implemented:
layout.css.conic-gradient.enabled,
turned off by default until it's implemented outside of WebRender

DevTools bug: n/a, devtools could potentially add a gradient editor, but
that's also applicable to linear/radial gradients

Other browsers: shipped since Chrome 69, Safari 12.1, Edge 79 and Opera 64

web-platform-tests:
https://searchfox.org/mozilla-central/search?q=conic-gradient=false=false=testing%2Fweb-platform

Restricted to secure contexts: No, CSS features are usually not restricted
to secure contexts

Is this feature enabled by default in sandboxed iframes?  Yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: MathML mfenced element

[Tim Smith]

On Fri, Dec 20, 2019 at 8:33 AM Mats Palmgren  wrote:
> In this case, the use counter is MathML_DeprecatedMfencedElement and it
> doesn't show up in the relevant page:
> https://georgf.github.io/usecounters/#kind=page=DEPRECATED=beta=72
> which I'm reading as "never occurred even once".
> I'm not very familiar with our telemetry though so I could be wrong...

That sounds right.

Our release-channel telemetry data samples a much wider audience but
isn't published externally. Since the 71 release on Dec 3 (which was
the first one containing the use counter), we've observed exactly one
load of a page containing mfenced across the entire telemetry-enabled
Firefox release population. [1]

Cheers,
Tim

[1] https://sql.telemetry.mozilla.org/queries/67235/source (mozilla
LDAP required)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Removing the XUL grid implementation

[Tim Nguyen]

Hello folks,

After a year of work, all XUL grid usages have been removed from Firefox!
The Thunderbird team also has been doing a lot of hard work on their side.

This means the XUL grid implementation can now be removed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1525737

I'm planning to remove the XUL grid implementation at the beginning of the
Firefox 78 cycle to leave time to address potential regressions from the last
removal <https://bugzilla.mozilla.org/show_bug.cgi?id=1583696> and for the
Thunderbird team to remove their last usage
<https://bugzilla.mozilla.org/show_bug.cgi?id=1632451>.

Thanks to everyone who reviewed my grid removal patches and to Daniel
Holbert and Emilio Cobos Àlvarez for the platform work that made this
possible!

Please let me know if you have any questions or concerns.

Cheers,
Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Update browsing context name on cross site navigation or history traversal

[Tim Huang]

Summary:

The window.name can persist after doing cross-origin navigation, which
means it can leak information across origins and be used as a tracking
vector.

To address this, we want to clear the window.name when doing cross-origin
navigations. The window.name won't persist across origins, so cannot be
used for tracking.

We also want to implement the store/restore window.name in the session
history when doing history loads. This has been defined in HTML Standard.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=444222

Standard:
  * https://html.spec.whatwg.org/#history-traversal

Platform coverage: All

Preference: privacy.window.name.update.enabled

Devtools bug: Nope.

Other browsers:
  * Safari has shipped this.
  * Chrome doesn't implement this.

web-platform-tests:
We will add web-platform-tests for this.

Secure contexts:
This is not restricted to secure contexts.

Is this feature enabled by default in sandboxed iframes?: Yes

Best,
Tim,
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: CSS conic-gradient

[Tim Nguyen]

Summary: CSS conic-gradients allow developers to specify gradients that
start from a certain angle where color stops are placed around the
circumference of a circle centered around a specified point.

Thanks to my friend Mohamed's work on Direct2D
, full Windows
support is now available, so this can now be enabled by default everywhere.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=conic-gradients

Standard: https://drafts.csswg.org/css-images-4/#conic-gradients

Target Release: 83

Platform coverage: All, but printing support will arrive after Cairo support
.

Preference for feature: On by default (layout.css.conic-gradient.enabled)

DevTools bug:

   - Output parser support (angle/color swatches) was done in bug 1621794
   
   - CSS autocomplete works
   - Prototype for a linear-gradient visualizer was done in bug 1364380
    as pointed out by
   Patrick in the last email thread

Other browsers: shipped since Chrome 69, Safari 12.1, Edge 79 and Opera 64

web-platform-tests:
https://searchfox.org/mozilla-central/search?q=conic-gradient=false=false=testing%2Fweb-platform
Many parsing tests along with few rendering tests were already there,
although many were added at the beginning of the year in bug 1616986
.

Restricted to secure contexts: No, CSS features are usually not restricted
to secure contexts

Is this feature enabled by default in sandboxed iframes? Yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Network Partitioning

[Tim Huang]

Intent to ship: Network Partitioning

# Summary
There are many tracking vectors that can be used by advertising networks to
track users across websites. One major category of tracking vectors is
known as “Supercookies,” which are stored in browsers and are difficult for
users to detect and remove. The network state can be abused by trackers as
a “Supercookie” to track users. For example, the HTTP cache was not
designed for storing data like cookies, but it can be abused for the
purposes of tracking or identifying users [0][1].

Client-Side Storage Partitioning [2] has outlined the strategy that we are
going to adopt to protect users from the aforementioned problem. As a part
of it, Network partitioning implements the protection for network state.
When enabling network partitioning, Firefox will use the top-level site,
i.e., its URL’s scheme and URL’s host’s registrable domain (eTLD+1), as an
additional key for network state. In other words, when doing an HTTP cache
entry lookup, it will not only use the URL to search the entry but use the
URL keyed by the top-level site.

Note that partitioning network state could have a performance impact
because the network caches cannot be reused for different top-level sites.
A resource that has been cached for one top-level site still needs to make
a network request if another top-level site loads the same resource. This
could increase the overall loading time.

The protection of the Network Partitioning covers assorted network state,
including

   -

   HTTP cache
   -

   Image cache
   -

   Favicon cache
   -

   Connection pooling
   -

   StyleSheet cache
   -

   DNS
   -

   HTTP authentication
   -

   Alt-Svc
   -

   Speculative connections
   -

   Font cache
   -

   HSTS
   -

   OCSP
   -

   Intermediate CA cache
   -

   TLS client certificates
   -

   TLS session identifiers
   -

   Prefetch
   -

   Preconnect
   -

   CORS-preflight cache


We have enabled Network Partitioning since Firefox 78 in Nightly channel
and Firefox 83 in the early Beta channel. We will enable it by default in
Firefox 85. As Network Partitioning ships we will be running studies to
monitor the performance impact of these changes, and may adjust the
timeline if we find that it has a severe impact.


# Bug

https://bugzilla.mozilla.org/show_bug.cgi?id=1590107


# Standard

https://privacycg.github.io/storage-partitioning/

https://fetch.spec.whatwg.org/#http-cache-partitions


# Platform coverage

All


# Preference

privacy.partition.network_state


# DevTools bug

N/A


# Other browsers

Safari:

Safari has shipped the network partitioning since 2013, see
https://bugs.webkit.org/show_bug.cgi?id=110269.

Chrome:

Chrome has sent an intent-to-ship for partitioning the HTTP cache[3]. And
they have implemented the CORS-preflight cache partitioning. The metrics of
the performance impact of enabling HTTP cache partitioning in Chrome have
been summarized here[4].


# Web-platform-tests

https://github.com/web-platform-tests/wpt/blob/master/fetch/http-cache/split-cache.html

https://github.com/web-platform-tests/wpt/blob/master/cors/preflight-cache-partitioning.sub.window.js

[0]: https://polict.net/blog/web-tracking-via-http-cache-xs-leaks/

[1]: https://github.com/xsleaks/xsleaks

[2]: https://privacycg.github.io/storage-partitioning/

[3]:
https://groups.google.com/a/chromium.org/g/blink-dev/c/NUR-gpWxSZ4/m/9boB-VrlBwAJ

[4]:
https://github.com/shivanigithub/http-cache-partitioning#impact-on-metrics


Best,

Tim Huang,
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: XUL grid implementation

[Tim Nguyen]

Hi folks,

Thanks to Mats Palmgren & Rares Doghi, XUL grid got removed from tab prompts
<https://bugzilla.mozilla.org/show_bug.cgi?id=1583696>
(`alert`/`confirm`/`prompt`) last week, this was the last usage in
mozilla-central. If you notice any regressions, please file a bug and mark
it as a regression of bug 1583696
<https://bugzilla.mozilla.org/show_bug.cgi?id=1583696>.

All other XUL grid removals have baked for a year now.

With that being said, I'm planning to unship the XUL grid implementation in
Firefox 85 in bug 1525737
<https://bugzilla.mozilla.org/show_bug.cgi?id=1525737>, which includes:

   - the whole layout/xul/grid directory
   <https://searchfox.org/mozilla-central/source/layout/xul/grid>
   - the -moz-grid/-moz-grid-group/-moz-grid-line CSS display values
   - the // XUL elements

If you need grid-like functionality, alternatives are CSS grid or HTML
tables.
Please let me know if you have any concerns or questions.

Cheers,
Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Enable State Partitioning in Private Browsing Mode

[Tim Huang]

# Summary

We would like to enable State Partitioning[1] in private browsing windows.
State Partitioning has been enabled in Strict Mode since Firefox 86[2] to
provide better protection against trackers. Now, we want to expand the
protection to the private browsing mode so that more users could benefit
from State Partitioning.

We use the cookie behavior to decide if State Partitioning is enabled in
Firefox. We used to have one single pref to control the cookie behavior for
both regular and private browsing mode. To enable State Partitioning in
private mode, we will introduce a new pref
“network.cookie.cookieBehavior.pbmode” to control the cookie behavior in
private browsing mode. By doing this, we can control the cookie behavior
individually and enable State Partitioning in private browsing mode without
affecting regular mode.

Our current plan is to enable State Partitioning in private mode in Firefox
89. And it is expected to ride the trains.

Previous intent to prototype is here:
https://groups.google.com/g/mozilla.dev.platform/c/f2_hLdfsbq4/m/ZhuWE4ZAAgAJ?pli=1


# Bug

https://bugzilla.mozilla.org/show_bug.cgi?id=1698810


# Standard

https://github.com/privacycg/storage-partitioning/

Note that this spec is still a work in progress.


# Platform coverage

All


# Preference

network.cookie.cookieBehavior.pbmode


# DevTools Bug

None


# Other browsers

Chrome: Chrome blocks third-party cookies in incognito mode.

Safari: Safari blocks all third-party cookies by default.


Thanks,

Tim


[1]: https://hacks.mozilla.org/2021/02/introducing-state-partitioning/

[2]: https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Tim Guan-tin Chien]

On Fri, Jan 30, 2015 at 6:48 AM, Mike Hommey m...@glandium.org wrote:

 People using Git for Gecko development can also try a new workflow that
 doesn't involve gecko-dev at all.

 http://glandium.org/blog/?page_id=3438

 Mike

This sure look promising!

Any support for Level 1 people for creating a patch-to-commit for
attaching on Bugzilla?
I tried :jlebar's moz-git-tools once but the exported patch was broken for hg.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Browser API: iframe.executeScript()

[Tim Guan-tin Chien]

How about the risk of having API users intentionally creating local
APIs? For example, people can implement support for meta
apple-touch-icon just in Gaia.

I was told this is a concern back in B2G v1.0.

On Wed, Jun 17, 2015 at 5:52 AM, Jonas Sicking jo...@sicking.cc wrote:
 On Tue, Jun 16, 2015 at 10:33 AM, Bobby Holley bobbyhol...@gmail.com wrote:
 On Tue, Jun 16, 2015 at 10:06 AM, Paul Rouget p...@mozilla.com wrote:

 What would be the right approach to allow such a feature?
 Would adding a new permission help?

 Well, it sorta depends on what you're trying to accomplish. browser.html is
 supposed to be creating a web browser using only the web, right?

 I really hope we're *not* trying to accomplish that. It will probably
 never be possible to implement a web browser using just web
 technologies.

 A web browser needs the ability to do things like clearing cookies for
 arbitrary domains, rendering websites that doesn't want to be iframed,
 and grant/deny websites the ability to use geolocation. We don't want
 arbitrary websites to be able to do those things.

 / Jonas
 ___
 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: Web API equivalent of nsIEffectiveTLDService / publicsuffix.org database?

[Tim Guan-tin Chien]

On Mon, Aug 10, 2015 at 3:12 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Sun, Aug 9, 2015 at 2:51 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Sun, Aug 9, 2015 at 4:00 AM, Andrew Sutherland
 asutherl...@asutherland.org wrote:
 Are there any plans to surface the contents of
 https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIEffectiveTLDService
 from https://publicsuffix.org/ via a web-facing URI?

 There is https://www.w3.org/Bugs/Public/show_bug.cgi?id=25865 which is
 about more formally defining eTLDs and perhaps even exposing an API.
 However, it's unclear whether exposing an API is a good thing. eTLDs
 are used for cookies, storage boundaries in certain browsers, and
 document.domain. However, nobody is really pleased with that situation
 and wishes everything used origins instead.

 So it's unclear whether to embrace eTLDs or retain hope that we can
 slowly rid ourselves of features that depend on them.

 Changing cookies seems unlikely to happen on any relevant timescale.

 Andrew, could you simply pull this data directly from publicsuffix.org
 and cache locally?


The list ... changes a few times per month [1]. What's the
consequence of using an outdated list in the app?

[1] https://publicsuffix.org/list/


 / Jonas
 ___
 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: Should the entire JS structure be Object.freeze()'d if it's exposed through a read only property?

[Tim Guan-tin Chien]

On Fri, Jul 10, 2015 at 2:45 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 7/9/15 4:48 AM, Tim Guan-tin Chien wrote:

 In this case, I modified the manifest object passed from mozApp API,
 and the object was subsequently removed by the platform, so did my
 modifications. Fabrice said I should not be modified the object since
 it's marked as read only in WebIDL.


 readonly just means the property has a getter but no setter.  Whether you
 can then modify the value returned by the getter is a separate issue that
 needs to be considered as part of designing an API.

 I wonder if platform should
 protect web authors more by simply freeze the entire structure when
 giving it to the content.


 If it were a dictionary, you could use
 https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings#Frozen.
 But note that freezing is not recursive, so if some of the properties are
 themselves objects _they_ could still be mutated...

 Are there any other APIs expose a structure like this?


 Looks like we only use [Frozen] on sequences at the moment...

 -Boris

Thanks for reply :bz.

In that case, the right question to ask would be (A) should
DOMApplication#manifest be a recursive frozen JS structure, and maybe
(B) should WebIDL binding provide an keyword like DeepFrozen that
could recursive freeze the exposed structure.

In essence, (A) is the API design question, (B) is the infrastructure
needed should answer to (A) is an yes.

I would personally vote yes on both (A) and (B).


Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Should the entire JS structure be Object.freeze()'d if it's exposed through a read only property?

[Tim Guan-tin Chien]

Hi,

I want to call out on a confusion here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1176184#c12

In this case, I modified the manifest object passed from mozApp API,
and the object was subsequently removed by the platform, so did my
modifications. Fabrice said I should not be modified the object since
it's marked as read only in WebIDL.

I am currently working on changing my code there so I won't be
modifying the manifest object, but, I wonder if platform should
protect web authors more by simply freeze the entire structure when
giving it to the content.

Are there any other APIs expose a structure like this?


Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NPAPI plug-in use case: certified medical devices

[Tim Guan-tin Chien]

Will either js-ctypes or child process-calling add-on passes AMO
review? With signing requirement those add-ons would not be allow to
run in Firefox without signing from AMO at all right?

On Fri, Aug 28, 2015 at 11:42 PM, Benjamin Smedberg
benja...@smedbergs.us wrote:


 On 8/28/2015 10:25 AM, Tony wrote:

 Our product makes use of a 3rd party medical device that requires a C
 library for usage.  We created a NPAPI plugin that wraps this C library so
 we can access the device from JavaScript.

 Here's where the lawyers get involved...

 The medical device, **including** the software included with the device
 are FDA certified.  We (as an user of the device) are not allowed to provide
 our own software to access the device (which we could do without much
 effort).  We have to use the certified C library.

 The manufacture of the device (and its library) do not wish to share their
 Intellectual Property (IP) with us so that we could create a modern
 browser extension.  As most of their customers use their product with native
 OS clients, not browser based clients.


 I recommend that you write this as a Firefox addon in the following way:

 * construct a shim program which links the C library and communicates with
 the addon on stdin/stdout
 * use the addon SDK and system/child_process to launch your shim program and
 communicate with it

 See
 https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/system_child_process
 for a description of system/child_process.

 I'm going to contradict Ehsan here: ctypes is a powerful-but-dangerous API
 and I wouldn't recommend it unless you have no other choice. We may decide
 to stop supporting it in the future.

 --BDS


 ___
 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: Smart Card and WebCrypto (Re: On the future of keygen and application/x-x509-*-cert MIME handling)

[Tim Guan-tin Chien]

On Sun, Aug 30, 2015 at 5:37 PM, Tim Guan-tin Chien
timdr...@mozilla.com wrote:
 It seems a potential future for that which works within the web's
 security model is FIDO, see

   https://fidoalliance.org/
   https://support.google.com/accounts/topic/6103521

 Indeed, banks in Taiwan are slowly rolling out OTA based
 authentications primary mobile app banking users, despite 100% of the
 ATM cards are already smart cards (required by legal mandate against
 forgery since 2006) and you can already access back accounts from
 WebATM websites  smart card readers with -- again, ActiveX or Java
 plug-in.

Sorry, this should be s/OTA/OTP/ -- one time password devices and
authentications.

(too much FxOS for me...)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Smart Card and WebCrypto (Re: On the future of keygen and application/x-x509-*-cert MIME handling)

[Tim Guan-tin Chien]

Thanks for the note.

On Sun, Aug 30, 2015 at 1:50 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Sun, Aug 30, 2015 at 7:33 AM, Tim Guan-tin Chien
 timdr...@mozilla.com wrote:
 It's also worthy to point out many nation-state deploys Smart Card
 identifications (despite the privacy concern), allow it's citizens (or
 subjects) to authenticate with government services online.

 It seems a potential future for that which works within the web's
 security model is FIDO, see

   https://fidoalliance.org/
   https://support.google.com/accounts/topic/6103521

Indeed, banks in Taiwan are slowly rolling out OTA based
authentications primary mobile app banking users, despite 100% of the
ATM cards are already smart cards (required by legal mandate against
forgery since 2006) and you can already access back accounts from
WebATM websites  smart card readers with -- again, ActiveX or Java
plug-in.

I can't argue if either is securer or better compare to another, but
it's important to acknowledge we cannot change the banking industry or
government IT service industry over night by refusing providing
solutions.

 I don't think we're currently working on this though.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Smart Card and WebCrypto (Re: On the future of keygen and application/x-x509-*-cert MIME handling)

[Tim Guan-tin Chien]

It's also worthy to point out many nation-state deploys Smart Card
identifications (despite the privacy concern), allow it's citizens (or
subjects) to authenticate with government services online.

Filing income tax online is the only use case for me personally to use
an Windows VM (for IE  ActiveX) or a Java plug-in. Web has so far
failed to fulfill this use case as essential and certain as death [1].

In Taiwan, 45% of tax filing is through Smart Cards online [2] this
year. The alternatives would be go down to the tax office to file it
on paper, or authenticate in person to get the income manifest *and*
file online with the authenticated passcode printed on the manifest.
WebCrypto could save some trees by preventing people from having to do
that.

(I am not sure these are the right mailing list for raising the use
case -- please advice if this should go somewhere else.)

Thanks,


Tim

[1] https://en.wikipedia.org/wiki/Death_and_taxes_%28idiom%29
[2] 
https://tw.news.yahoo.com/%E8%87%AA%E7%84%B6%E4%BA%BA%E6%86%91%E8%AD%89%E7%B6%B2%E8%B7%AF%E5%A0%B1%E7%A8%85-%E5%86%8D%E5%89%B5%E6%96%B0%E9%AB%98-093200374.html

On Thu, Aug 20, 2015 at 8:39 PM, helpcrypto helpcrypto
helpcry...@gmail.com wrote:
 I know a lot of colleagues with the same problem, and that's why there has
 been a rumble about out of scope smartcards on Webcrypto.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Tim Guan-tin Chien]

On Fri, Dec 4, 2015 at 7:01 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>
> On Fri, Dec 4, 2015 at 2:43 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
> >
> > Sure. Conversely, I don't find myself convinced by your position.
> >
> > Would be happy to talk about this live if you think that's useful.
> >
>
> Probably not ... these are judgement calls that are difficult to resolve.
>
> Rob

Rob,

IMHO there will be some detail to settle for (1) since that implies
hardware vendor has to host a driver for the device to work,
_forever_.

We could get around it by amending (1) into having vendor shipping a
JS library as driver, which fold it into (4) (if I understand it
correctly). But then we would lost the benefit of getting vendors to
supply security update timely and block bad API calls from apps.

I am leaning toward Ekr's opinion in this case. The way hardware
vendors divide their works also prevent the actual chip vendor (OEM)
from providing end user support (by at least host a driver).

Thanks,


Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: WebUSB

[Tim Guan-tin Chien]

On Wed, Dec 9, 2015 at 4:55 PM, Tim Guan-tin Chien <timdr...@mozilla.com> wrote:
> On Fri, Dec 4, 2015 at 7:01 PM, Robert O'Callahan <rob...@ocallahan.org> 
> wrote:
>>
>> On Fri, Dec 4, 2015 at 2:43 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>
>> >
>> > Sure. Conversely, I don't find myself convinced by your position.
>> >
>> > Would be happy to talk about this live if you think that's useful.
>> >
>>
>> Probably not ... these are judgement calls that are difficult to resolve.
>>
>> Rob
>
> Rob,
>
> IMHO there will be some detail to settle for (1) since that implies
> hardware vendor has to host a driver for the device to work,
> _forever_.
>
> We could get around it by amending (1) into having vendor shipping a
> JS library as driver, which fold it into (4) (if I understand it
> correctly). But then we would lost the benefit of getting vendors to
> supply security update timely and block bad API calls from apps.
>
> I am leaning toward Ekr's opinion in this case. The way hardware
> vendors divide their works also prevent the actual chip vendor (OEM)
> from providing end user support (by at least host a driver).
>

The (4) here is the one Jonas wrote:

> 4) Design a new USB-protocol which enables USB devices to indicate
> that they are "web safe" and which lets the USB device know which
> website is talking to it. Then let the user authorize a website to use
> a given device.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML mozbrowser frames on desktop Firefox?

[Tim Guan-tin Chien]

What prevents you from using ? Is it because the parent
frame is (X)HTML?

I don't know what prevents browser-element from being enabled on desktop
though -- it's tests are running on desktop, and the actual feature is
hidden behind a permission so we won't expose it to the web content even if
we turn it on.


On Fri, Jan 8, 2016 at 3:31 PM, J. Ryan Stinnett  wrote:

> (CCing dev-platform as suggested on IRC.)
>
> On Thu, Jan 7, 2016 at 9:58 PM, J. Ryan Stinnett  wrote:
> > DevTools is working on rebuilding the responsive design UI in an HTML,
> > chrome-scoped page. This page will want to manage child frames to show
> > the page content, which could be remote frames. So, I would want to
> > use  for cases like these.
> >
> > However, I noticed mozbrowser frames are currently preffed off
> > (dom.mozBrowserFramesEnabled) on desktop. Is there a reason for this?
> > Can it be turned on, or is there some kind of work still needed before
> > it is usable?
> >
> > I assume we would eventually want to enable this anyway, so that HTML
> > frames can be used in the primary browser UI.
> >
> > - Ryan
> ___
> 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: unowned orange by team

[Tim Guan-tin Chien]

On Wed, Dec 23, 2015 at 9:15 AM, Ben Kelly  wrote:
> fxos:
> 24) https://bugzilla.mozilla.org/show_bug.cgi?id=999675

I've just disabled this test.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ESLint is now available in the entire tree

[Tim Guan-tin Chien]

The Gecko JavaScript is also littered with #ifdef and # is really not a
token for comment in JS... is there any plan to migrate that away since
there is ESLint present?

On Sun, Nov 29, 2015 at 10:37 PM, Vivien Nicolas 
wrote:

> On Sun, Nov 29, 2015 at 2:30 PM, David Bruant  wrote:
>
> > Hi,
> >
> > Just a drive-by comment to inform folks that there is an effort to
> > transition Mozilla JavaScript codebase to standard JavaScript.
> > Main bugs is: https://bugzilla.mozilla.org/show_bug.cgi?id=867617
> >
> > And https://bugzilla.mozilla.org/show_bug.cgi?id=1103158 is about
> > removing non-standard features from SpiderMonkey.
> > Of course this can rarely be done right away and most often requires
> > dependent bugs to move code to standard ECMAScript (with a period with
> > warnings about the usage of the non-standard feature).
> >
>
> What about .jsm modules ? Or is that not really considered ?
>
> I have been told that ES6 modules may help to solve some of the problems
> covered by .jsm but I don't see how you can create a ES6 module that is can
> be accessed from multiple js context from the same origin. Mostly
> interested as it would be nice to be able to write a module once and share
> it between multiple tabs instead of having to reload the same JS script for
> all similar tabs, like all the bugzilla tabs many of us have open for
> example.
> ___
> 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: ESLint is now available in the entire tree

[Tim Guan-tin Chien]

Thanks, bug 1150859 only covers ./browser/.
Is this a done deal which we want to get rid of #ifdef in all JS code
everywhere?

(My particular interest would be obviously ./dom/ and ./b2g/)

On Mon, Nov 30, 2015 at 5:44 PM, Gijs Kruitbosch <gijskruitbo...@gmail.com>
wrote:

> Yes. See bug 1150859 and friends.
>
> ~ Gijs
>
> On 30/11/2015 09:05, Tim Guan-tin Chien wrote:
>
>> The Gecko JavaScript is also littered with #ifdef and # is really not a
>> token for comment in JS... is there any plan to migrate that away since
>> there is ESLint present?
>>
>> On Sun, Nov 29, 2015 at 10:37 PM, Vivien Nicolas <vnico...@mozilla.com>
>> wrote:
>>
>> On Sun, Nov 29, 2015 at 2:30 PM, David Bruant <bruan...@gmail.com> wrote:
>>>
>>> Hi,
>>>>
>>>> Just a drive-by comment to inform folks that there is an effort to
>>>> transition Mozilla JavaScript codebase to standard JavaScript.
>>>> Main bugs is: https://bugzilla.mozilla.org/show_bug.cgi?id=867617
>>>>
>>>> And https://bugzilla.mozilla.org/show_bug.cgi?id=1103158 is about
>>>> removing non-standard features from SpiderMonkey.
>>>> Of course this can rarely be done right away and most often requires
>>>> dependent bugs to move code to standard ECMAScript (with a period with
>>>> warnings about the usage of the non-standard feature).
>>>>
>>>>
>>> What about .jsm modules ? Or is that not really considered ?
>>>
>>> I have been told that ES6 modules may help to solve some of the problems
>>> covered by .jsm but I don't see how you can create a ES6 module that is
>>> can
>>> be accessed from multiple js context from the same origin. Mostly
>>> interested as it would be nice to be able to write a module once and
>>> share
>>> it between multiple tabs instead of having to reload the same JS script
>>> for
>>> all similar tabs, like all the bugzilla tabs many of us have open for
>>> example.
>>> ___
>>> 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: now available on desktop Firefox

[Tim Guan-tin Chien]

This implies the Gaia System app, which is framed by shell.html (a
chrome document), will switch cookie jar when the default is changed,
no?

(I am for simplying cookie jar shenanigans -- we have been workaround
that in Gaia for too long!)

On Tue, Mar 8, 2016 at 10:00 AM, Jonas Sicking  wrote:
>
> On Mon, Mar 7, 2016 at 1:55 PM, J. Ryan Stinnett  wrote:
> > By default,  can't access the storage used by
> >  for cookies and other site data, making it hard to share page
> > state across the two browser frame types. An additional feature  > mozbrowser noisolation> has been added, which gives the frame access to the
> > same storage as . This is only meant for use on desktop
> > Firefox to allow HTML and XUL browser frames to work together.
>
> Is there a reason we couldn't make 'noisolation' the default behavior
> when  is used by chrome code?
>
> There is currently work going on in Gecko to enable use of multiple
> "cookie jars" in Firefox, this is heavily based on the cookie jar
> implementation that we wrote for FirefoxOS, but it is cleaned up and
> simplified.
>
> I suggest we use that support rather than the old FirefoxOS cookie
> jars. The main reason is that you'll have to deal with painful data
> migration once the new isolation is fully in place.
>
> In practice I expect all data in other cookie jars to be deleted
> rather than migrated at some point in the future.
>
> So what I'm suggesting is:
> * Make  act as if 'noisolation' is set when the
> element is used in chrome documents (documents with a system
> principal).
> * Add support for  similar to
>  which already exist.
>
> Sorry for not noticing this earlier in the new  work.
>
> / Jonas
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: now available on desktop Firefox

[Tim Guan-tin Chien]

I am confused. In your proposal, are you referring to the chrome
*user/embedder* of  (e.g. shell.html), or a chrome
*embedded* page (I am not aware of any example).


Tim

On Tue, Mar 8, 2016 at 2:06 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Mon, Mar 7, 2016 at 9:51 PM, Tim Guan-tin Chien <timdr...@mozilla.com> 
> wrote:
>> This implies the Gaia System app, which is framed by shell.html (a
>> chrome document), will switch cookie jar when the default is changed,
>> no?
>
> No, the Gaia System app doesn't run as chrome (i.e. doesn't have a
> system principal). So it would not be affected by this proposal.
>
> / Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Submit to MozReview using Git

[Tim Guan-tin Chien]

Thanks for the pointer! I ended up re-do the cloning from hg instead.

I would recommend the mozreview docs points to these document and explicit
states the origin of local clone mozreview is supposedly to work with.


Tim

On Wed, Mar 2, 2016 at 6:13 PM, Ting-Yu Lin <t...@mozilla.com> wrote:

> > ~/repo/gecko/gecko-dev master$ git mozreview configure
> > searching for appropriate review repository...
> > warning: error trying to resolve Mercurial changesets
>
> I saw the same error before. After setting mozilla-central in my git repo
> remote described in the following wiki, I can setup review repository
> successfully. I'm not sure this is a require steps because the manual to
> setup mozview by using git may assume the git repo was fresh cloned by
> git-cinnabar.
>
>
> https://github.com/glandium/git-cinnabar/wiki/Mozilla:-Using-a-git-clone-of-gecko%E2%80%90dev-to-push-to-mercurial#switching-to-git-cinnabar
>
>
> Ting-Yu
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Submit to MozReview using Git

[Tim Guan-tin Chien]

Hi :gps,

I am following the description here and try to set up git-mozreview on my
local gecko-dev clone. Here is the error I got:

~/repo/gecko/gecko-dev master$ git mozreview configure
searching for appropriate review repository...
warning: error trying to resolve Mercurial changesets

Could you recommend how I should debug this? All repo was cloned yesterday
and git/mercurial are all up-to-date from Homebrew

$ git --version
git version 2.7.2
$ hg --version
Mercurial Distributed SCM (version 3.7.1)

Thanks!


Tim



On Fri, Feb 12, 2016 at 11:05 PM, Wander Lairson Costa <wco...@mozilla.com>
wrote:

> \o/
>
> 2016-02-05 19:05 GMT-02:00 Nicholas Alexander <nalexan...@mozilla.com>:
> > On Fri, Feb 5, 2016 at 12:24 PM, Gregory Szorc <g...@mozilla.com> wrote:
> >
> >> It is now possible to submit reviews to MozReview using Git.
> Instructions
> >> are at
> >>
> >>
> https://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview/install-git.html
> >>
> >> Bugs should be filed against Developer Services :: MozReview.
> #mozreview is
> >> your support IRC channel.
> >>
> >
> > Wow!  Great work gps and everybody else  involved!
> >
> > Nick
> > ___
> > dev-version-control mailing list
> > dev-version-cont...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-version-control
>
>
>
> --
> Cheers,
> Wander
> ___
> 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: Cancel your old Try pushes

[Tim Guan-tin Chien]

Any conclusions out of the discussion here? Try is getting slower as we
speak...

I would opt to less disruptive way at first, per what Brian Grinstead said.
We don't even have to implement interactive prompt first. If that makes
people cancel old Try runs more, great, if not, we could consider other
workflow-breaking solutions.

I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1266602 for this.


On Tue, Apr 19, 2016 at 2:54 AM, William Lachance 
wrote:

> On 2016-04-18 2:46 PM, William Lachance wrote:
>
>>
>> Treeherder did trigger a rather large memory leak which got fixed in the
>> browser a while back (Dec 2015), so please consider revisiting it if you
>> gave up around then:
>> ...
>> If anyone feels like profiling and submitting patches, we'd welcome the
>> help. :) Getting a UI-only development environment going is trivial:
>> http://treeherder.readthedocs.org/ui/installation.html#installation
>>
>
> Just realized that this last comment might make it seem like I'm passing
> the buck, which wasn't my intention. :) I do have a lot of other things to
> do, but if you continue to have problems using treeherder due to memory
> leaks or whatever feel free to file a bug against treeherder and needinfo
> me; I promise to give it my attention.
>
> Will
>
> ___
> 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: Cancel your old Try pushes

[Tim Guan-tin Chien]

I wonder if there is any use cases to do multiple Try pushes of different
changesets but with the same bug number. Should we automatically cancel the
old ones when there is a new one?

On Fri, Apr 15, 2016 at 8:47 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> I'm sure most of you have experienced the pain of long backlogs on Try
> (Windows in particular). While we'd all love to have larger pools of test
> machines (and our Ops people are actively working on improving that!), one
> often-overlooked thing people can do to help with the backlog Right Now is
> to cancel pending jobs on pushes they no longer need (i.e. newer push to
> Try, broken patch, already pushed to inbound, etc).
>
> Treeherder makes it easy to do this - just hit the little circle with an X
> icon on the right hand side adjacent to the "XX% - Y in progress" text
> along the top bar of the push. You will be prompted whether you really want
> to cancel all jobs on the push. Just hit OK and you're done.
>
> Killing off unnecessary jobs can have a significant impact on wait times
> and backlog, so your consideration is greatly appreciated!
>
> Thanks,
> Ryan
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: URL translation map Re: MXR permanently offline, please transition to DXR

[Tim Guan-tin Chien]

I didn't file the bug because I don't know if it make sense to rewrite on
the source tree (instead of implementing the rewrite). Feel free to file.
Thanks.

On Wed, Jul 6, 2016 at 9:38 PM, Mike Hoye <mh...@mozilla.com> wrote:

> On 2016-07-06 1:46 AM, Tim Guan-tin Chien wrote:
>
> We really need to get the vanilla redirect done at least, since,
> ironically, "mxr.mozilla.org" is even referenced in the code base!
>
>
> https://dxr.mozilla.org/mozilla-central/search?q=mxr.mozilla.org=false
>
>
> Cleaning those up is a good first bug, I think. Is that one filed yet? If
> not, I'll file it directly.
>
> - mhoye
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mercurial performance (vs git)

[Tim Guan-tin Chien]

This looks really great until I realized it did not print dirty state.

There is probably no way to get the state without, say, `git status
--porcelain --u=no`, right?

On Tue, Aug 16, 2016 at 4:09 AM, Gregory Szorc  wrote:

> I use Facebook's scm-prompt.sh from
> https://bitbucket.org/facebook/hg-experimental/src/
> 3a45413794a0252a817e7e1fda02182658b85183/scripts/scm-prompt.sh.
> It works with both Git and Mercurial and is fast because it pokes at the
> repo internals directly instead of going through `git` or `hg`.
>
> On Mon, Aug 15, 2016 at 12:46 PM, Botond Ballo  wrote:
>
> > Cross-posting to dev-version-control
> >
> > On Mon, Aug 15, 2016 at 3:39 PM,   wrote:
> > > For the last few months I've been mostly using git clone of
> > mozilla-central because I'm used to git. Now I'm trying to set up my
> > mercurial environment to match what I have for git in order to reduce the
> > bias toward the latter.
> > >
> > > One of the crucial parts of my workflow is the git completion shell
> > prompt that gives me information about branch I'm on and
> untracked/modified
> > files.
> > >
> > > This is how my shell prompt looks like on gecko-dev (git clone):
> > >
> > > zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$
> > >
> > > and if I modify any file it may look like this:
> > >
> > > zbraniecki@cintra:~/projects/mozilla/gecko-dev (master +%>)$
> > >
> > > I tried to get something similar for HG, including hg-prompt (written
> in
> > python), and vcsprompt (written in C), but both are painfully slow.
> > >
> > > What's striking, on the same repo, the git is 3 times faster than hg to
> > get me the prompt shell.
> > >
> > > zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$ time
> > vcprompt -f "( %b %u%%%m)"
> > > ( master ?%)
> > > real0m0.472s
> > > user0m0.236s
> > > sys 0m0.384s
> > >
> > > vs
> > >
> > > zbraniecki@cintra:~/projects/mozilla/mozilla-central$ time vcprompt -f
> > "( %b %u%%%m)"
> > > ( default %+)
> > > real0m1.643s
> > > user0m1.224s
> > > sys 0m0.396s
> > >
> > >
> > > I thought that maybe it's just vcprompt, so I tried status:
> > >
> > > zbraniecki@cintra:~/projects/mozilla/mozilla-central$ time hg status
> > >
> > > real0m1.706s
> > > user0m1.380s
> > > sys 0m0.316s
> > >
> > > vs.
> > >
> > > zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$ time git
> > status
> > > On branch master
> > > Your branch is up-to-date with 'origin/master'.
> > >
> > > real0m0.399s
> > > user0m0.204s
> > > sys 0m0.332s
> > >
> > > If I understand correctly our choice of using mercurial over git was
> > driven by the performance. Am I doing something wrong?
> > >
> > > It seems like the performance difference is quite substantial.
> > >
> > > zb.
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > ___
> > dev-version-control mailing list
> > dev-version-cont...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-version-control
> >
> ___
> dev-version-control mailing list
> dev-version-cont...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-version-control
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Tim Guan-tin Chien]

Hi Dave,

I am glad that we are having this conversation. To be honest, two of
features spinning in Taipei are already partly implemented in HTML,
out of the expectations that, dealing with familiar tech means faster
development and less regressions. They are

- Desktop video control UI within 
https://bugzilla.mozilla.org/show_bug.cgi?id=1271765
- The date/time picker to popup from  and  https://bugzilla.mozilla.org/show_bug.cgi?id=888320

Things are obviously not as perfect as we would have imagined. I would
say the outstanding complications learned are the quirks of the XUL
embedder. The video control is implemented in HTML but within a XUL
anno node. The pickers are implemented in an XHTML embedded inside an
xul:panel > xul:iframe. By looking at the
patches/follow-up/regressions there you will see how much code would
still be live inside XBL (e.g. event forwarding), and one unfortunate
layout surprise (bug 173).

We would need to look at that more broadly to achieve the goal stated.
That could even mean re-invest in some XUL layout features if we must.

Within HTML, a longer discussion is needed (and intentional decisions
outside of HTML features) on how components in HTML should work. Gaia
was started in 2011 and became hard to work with quickly due to
various reasons, and compartmentalization being one of the biggest. I
will stop here as an effort of stop beating the dead horse.

DevTools team is using React. We should be ready to make a similar
decision when we need to — single-page-web-app needs a committed way
of compartmentalization to stay sane, i.e. something (platform feature
or not) is needed here to replace XBL.

Yeah, the Web Components. I've been hearing about this ever since my
employment in Mozilla. Yet, around 2015, I was told the current
pref-off implementation will likely be changed as the spec matures so
front-end should not build anything on top of it. I don't know if the
status has changed but I will personally back away from it before I am
given a strong commitment from the platform engineering.

Feel free to reach out. Thanks,


Tim


On Tue, Jan 17, 2017 at 4:43 AM, Dave Townsend <dtowns...@mozilla.com> wrote:
> One of the things I've been investigating since moving back to the desktop
> team is how we can remove XUL from the application as much as possible. The
> benefits for doing this are varied, some obvious examples:
>
> * XUL is a proprietary standard and we barely maintain it.
> * Shallower learning curve for new contributors who may already know and use
> HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team have
> been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

[Tim Guan-tin Chien]

Hi :gps,

The more I read into this, the more I think the hook might not likely fix
things. The hook would reject rename-only commits, but the hook would
likely not reject a rename commit from |foo| to |bar| and another rename
commit from |bar| to |Foo|.

These two commits, as you pointed out, would still produce problems when
someone checks out the repo.

Are we going to have the hook reject mismatched case of every filename ever
existed? That would be the only way to get away from any problems.


On Sun, Aug 28, 2016 at 2:30 AM, Mike Conley <mcon...@mozilla.com> wrote:

> Yes, thank you Kan-Ru!
>
> On Aug 27, 2016 2:10 PM, "Nick Fitzgerald" <nfitzger...@mozilla.com>
> wrote:
>
> > Thanks Kan-Ru! I've personally tried to include the header with the wrong
> > case multiple times, so I appreciate this change a lot.
> >
> > On Fri, Aug 26, 2016 at 7:54 PM, Kan-Ru Chen <kc...@mozilla.com> wrote:
> >
> > > Hello,
> > >
> > > In Bug 1297276 I landed a patch to rename mozilla/unused.h to
> > > mozilla/Unused.h to make it more consistent with our other MFBT
> headers.
> > > Normally rename a header shouldn't cause too much trouble, however this
> > > rename is only changing the case so you might experience some problems
> > > on case insensitive filesystem.
> > >
> > > As pointed out by Tim in
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1297276#c19 if you use
> > > |git pull -f| to update local copy of gecko and git refuse to, you can
> > > rm mfbt/unused.* first to make git happy.
> > >
> > > HPH
> > > Kanru
> > > ___
> > > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is Big5 form submission fast enough?

[Tim Guan-tin Chien]

According to Alexa top 100 Taiwan sites and quick spot checks, I can only
see the following two sites encoded in Big5:

http://www.ruten.com.tw/
https://www.momoshop.com.tw/

Both are shopping sites (eBay-like and Amazon-like) so you get the idea how
forms are used there.

Mike reminded me to check the Tax filing website: http://www.tax.nat.gov.tw/
.Yes, it's unfortunately also in Big5.


On Mon, May 15, 2017 at 3:33 PM, Henri Sivonen  wrote:

> On Fri, May 12, 2017 at 4:28 AM, Kan-Ru Chen  wrote:
> > On Thu, May 11, 2017, at 01:43 PM, Henri Sivonen wrote:
> >> In Firefox 43, I rewrote our Big5 support and, among other things, I
> >> optimized the *encoder* for footprint rather than speed on the theory
> >> that users won't notice anyway since the encoder run is followed by a
> >> dominating wait for the network when submitting a form.
> >>
> >> Since then, I've learned that the relative slowness of the Big5
> >> encoder is greater than I had anticipated. Still, I haven't seen
> >> anyone complaining, but I don't know if anyone who finds it too slow
> >> knows how to attribute the complaint.
> >>
> >> I'd like to hear from someone who uses a Web site/app that involves
> >> submitting a textarea of Traditional Chinese text in Big5 if the form
> >> submission performance seems normal (doesn't feel particularly slow)
> >> on low-performance hardware, like an Android phone. (In the phone
> >> case, I mean the amount of text you'd feel OK to input on a phone at
> >> one time.)
> >>
> >> If UTF-8 is so widely deployed that no one in the Taipei office needs
> >> to submit forms in Big5 anymore, that would be good to know, too.
> >
> > I don't feel that I see a lot of Big5 websites out there. It's hard for
> > me to even find one to test.
>
> Thank you. I guess it doesn't really matter whether Big5 form
> submission feels slow or not if it's something that people very rarely
> experience.
>
> >> Context:
> >> I need to decide if I should make Big5 encode faster or if I should
> >> trade off speed for smaller footprint for the legacy Simplified
> >> Chinese and Japanese *encoders*, too.
> >
> > I think Shift_JIS are still widely used. But this is just my experience
> > and guessing. If we really want to know the real word usage we should
> > collect data. Is there some telemetry probe for this already?
>
> If Big5 form submission is so rarely used that its performance doesn't
> matter, we can't then extrapolate the lack of complaints to inform the
> implementation Japanese or Simplified Chinese legacy encodings.
> Keeping the implementation approach asymmetry between Big5 on one hand
> and legacy Japanese and legacy Simplified Chinese encodings on the
> other hand seems like a valid approach in the case of a large
> disparity in usage today.
>
> There aren't telemetry probes for "this" regardless of what "this" you
> meant. To my knowledge, there's no telemetry probe for counting form
> submission encodings and there is no telemetry probe measuring form
> submission round trip time by encoding.
>
> Telemetry analysis in this area would have to be scoped by locale
> (e.g. analysis of relative frequency of Big5 and UTF-8 form
> submissions scoped to the zh-TW locale) to be meaningful, and, from
> experience, such analyses are annoying to carry out, because they need
> manual privileged access to telemetry data. Locale-scoped views aren't
> available on the telemetry dashboards, because some locales have so
> few users that scoping by locale would narrow the population so much
> that the data could be potentially too identifiable. It would be nice
> if locale-scoped views were available for locales whose
> telemetry-enabled instances are more numerous than some threshold.
> (Each of zh-TW, zh-CN and ja-JP surely has enough users, at least on
> the release channel, for aggregate data views not to be too
> identifiable.)
>
> Additionally, I don't really know what would be a good way to place a
> probe in our code to measure form submission round trip time (what the
> user perceives) rather than the encode step only. (It's already
> obvious that the encode step itself would show a disparity by a
> massive factor between UTF-8 and Big5.)
>
> (I don't think we need telemetry to believe that Shift_JIS and gbk
> form submissions still happen routinely.)
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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

Intent to ship: Use Songti TC and Songti SC as default font for zh locales

[Tim Guan-tin Chien]

Songti TC/SC are new Chinese serif fonts since OS X Mavericks.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1350766

Other vendors:

Chrome and Safari have already use it in their release version.

Extimated target release:

The above bug will ship it to early Beta 57 population and Nightly 57.
If it goes well we should ship this in Release 58.


Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Use Songti TC and Songti SC as default font for zh locales

[Tim Guan-tin Chien]

I have triggered autoland in
https://bugzilla.mozilla.org/show_bug.cgi?id=1419277 to ship this to
release.

Also, as we only support macOS >= 10.9, I've removed a few
old/duplicated old font names from the default font list for zh
locales as well.

On Thu, Sep 7, 2017 at 4:11 PM, Tim Guan-tin Chien <timdr...@mozilla.com> wrote:
> Songti TC/SC are new Chinese serif fonts since OS X Mavericks.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1350766
>
> Other vendors:
>
> Chrome and Safari have already use it in their release version.
>
> Extimated target release:
>
> The above bug will ship it to early Beta 57 population and Nightly 57.
> If it goes well we should ship this in Release 58.
>
>
> Tim
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: add_task() in HTML document will now wait for document to load

[Tim Guan-tin Chien]

Hi,

While working on other bugs, I realized if add_task() function calls are
scattered in multiple JS files or theologically multiple inline 

Re: PSA: nsIDocument is now mozilla::dom::Document.

[Tim Guan-tin Chien]

That's great! Definitely lower the barrier of entry for people new to Gecko
C++.

Just curious — what's the historical significance between nsIDocument and
nsDocument? I know "ns" stood for Netscape but what did "I" mean?

On Thu, Jan 3, 2019 at 3:56 PM Bobby Holley  wrote:

> This is awesome - thanks Emilio!
>
> On Thu, Jan 3, 2019 at 3:27 PM Emilio Cobos Álvarez 
> wrote:
>
> > I've always been slightly annoyed at the fact that Gecko used to have
> > multiple classes for the same concept of a document node without any
> > clear separation these days (nsIDocument and nsDocument).
> >
> > Over the last week I decided to change that by first merging both in:
> >
> >https://bugzilla.mozilla.org/show_bug.cgi?id=1516366
> >https://bugzilla.mozilla.org/show_bug.cgi?id=1516853
> >
> > And finally renaming nsIDocument to the more usual naming convention for
> > DOM objects / WebIDL-exposed things these days in:
> >
> >https://bugzilla.mozilla.org/show_bug.cgi?id=1517241
> >
> > So the end result is that now nsIDocument and nsDocument are the same
> > thing and are called mozilla::dom::Document.
> >
> > It was quite a big patch (thanks Olli for all the reviews!), but
> > over-all I think the end result is nicer.
> >
> > Anyhow, this is just a PSA since it's such a common type to be used, in
> > case you don't find something that used to live there :)
> >
> >-- Emilio
> > ___
> > 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