Re: Replacing PR_LOG levels

2015-05-23 Thread Eric Rahm
On Friday, May 22, 2015 at 12:06:05 PM UTC-7, David Rajchenbach-Teller wrote:
 On 22/05/15 04:06, Eric Rahm wrote:
  After a rather thorough examination of usages of each I have come up with a 
  set that I believe would fit our needs:
  
  enum class LogLevel {
Disabled = 0, // Logging is disabled for this module
Error,
Warning,
Info,
Debug,
  };
 
 I'll vote to have `Error` cause test failures unless explicitly whitelisted.
 
  
 
 
 -- 
 David Rajchenbach-Teller, PhD
  Performance Team, Mozilla

This is an interesting proposal. To make this work we'd need to:
  - Enable error level logging during test runs for all modules
  - Actually output the log level.
  - Do some automated analysis to figure out what needs to be whitelisted.

I'd suggest filing a bug to track this proposal (or perhaps split out a 
separate thread).

I think it could fit into the idea of structured logging as well, but as Nick 
pointed out that's some serious scope creep!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Replacing PR_LOG levels

2015-05-23 Thread Eric Rescorla
On Fri, May 22, 2015 at 3:36 PM, Eric Rahm er...@mozilla.com wrote:


  The above will also be surprising since it will work differently than
  other modules, making the same sorts of debugs appear at different
  levels.  This would be expecially confusing to people not frequently
  working in the module or when external users are asked to turn on
  debugging.

 This assumes log levels have been used consistently across modules, I can
 assure you that is not the case :) I hope that we can get to a more
 consistent state of course!

 I don't think it will be any more confusing when telling the external user
 what level to turn on (it's already rather confusing). Do we need super
 spammy? Turn on debug. Do we need just the basics? Turn on info.


I think the point that Jesup is making is that there is super spammy and
then there is absurd. And you
almost never want absurd but when you do you really do.

-Ekr
___
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)

2015-05-23 Thread Jesper Kristensen

Very nice, I am looking very much forward to using this.

It would be nice of you could also support paste. I agree that it is 
more sensitive, so maybe you could go with a user prompt in that case? 
The prompts as implemented in IE are horrible, but I think there could 
be many better ways of doing it.


Here is one way I have thought of how a prompt could look like, since 
you only allow it in relation to user interaction, you could make a 
prompt that looks like a context menu for the element the user 
interacted with, using a single word describing the action. I have 
implemented a mockup at http://jsfiddle.net/vvjcgj5g/1/ but I am sure 
Mozilla UX people could come up with better ways to do this. (My mockup 
has a prompt for all three actions, but you could do it for paste only)


/Jesper Kristensen

Den 05-05-2015 kl. 23:51 skrev Ehsan Akhgari:

Summary: We currently disallow programmatic copying and cutting from JS for
Web content, which has relied on web sites to rely on Flash in order to
copy content to the clipboard.  We are planning to relax this restriction
to allow this when execCommand is called in response to a user event.  This
restriction mimics what we do for other APIs, such as FullScreen.

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

Link to standard: This is unfortunately not specified very precisely.
There is a rough spec here: 
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#miscellaneous-commands
and the handling of clipboard events is specified here: 
https://w3c.github.io/clipboard-apis/.  Sadly, the editing spec is not
actively edited.  We will strive for cross browser interoperability, of
course.

Platform coverage: All platforms.

Target release: Firefox 40.

Preference behind which this will be implemented: This won't be hidden
behind a preference, as the code changes required are not big, and can be
easily reverted.

DevTools bug: N/A

Do other browser engines implement this: IE 10 and Chrome 43 both implement
this.  Opera has adopted this from Blink as of version 29.

Security  Privacy Concerns: We have discussed this rather extensively
before: http://bit.ly/1zynBg7, and have decided that restricting these
functions to only work in response to user events is enough to prevent
abuse here.  Note that we are not going to enable the paste command which
would give applications access to the contents of the clipboard.

Web designer / developer use-cases: This feature has been rather popular
among web sites.  Sites such as Github currently use Flash in order to
allow people to copy text to the clipboard by clicking a button in their UI.

Cheers,



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