Re: Screen Capture
On Thu, Oct 23, 2014 at 11:39 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Oct 24, 2014 at 10:10 AM, Jet Villegas j...@mozilla.com wrote: 1. Web-facing or not? I don't think we can. 1) We could ask for permission... 2) We could perhaps have some concept of taking a snapshot of the current page or indicated fragment so we can analyze it asynchronously. Then if a known-bad thing was found, such as a plugin, native form control, or non-CORS cross-origin image, we would reject. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
Le 24 oct. 2014 à 09:48, Anne van Kesteren ann...@annevk.nl a écrit : 1) We could ask for permission… yes. To take account that sometimes people forget they gave a permission. So maybe it should be a one-off permission only. (Just thinking) Some other things that could be done: * A visual notification and/or bell. In Japan, mobile phones have a mandatory shutter sound when you are taking a photo for privacy reasons, aka people around you MUST know that you are taking a photo. Here we can imagine that the user MUST know that a screen capture has been done. and/or we can imagine a system where when a screen capture is made there is a mandatory interaction of the user after it was taken (like the screenshots is shown) * history log records of screenshots. We can have a system where the user can see the date/site when screenshots have been taken. It creates other privacy implications in shared computers environments (family/companies/internet cafes). fun… :) -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On Thu, Oct 23, 2014 at 2:10 PM, Jet Villegas j...@mozilla.com wrote: Kicking off this thread to get a discussion on: 1. Web-facing or not? I think we have to make it web facing. If we want the web to be competitive with other platforms, which I hope we do, we have to expose this functionality. However it definitely has a lot of 2. Security/Privacy concerns so we'd have to be careful with how we do it. For example always showing an on-screen indicator indicating that the screen is currently shared. And reminding the user that password etc can be read by the remote party. And forcing the user to explicitly choose the option rather than just clicking a yes button (aka 'whatever button') might be a good idea. It would also be cool to enable sharing just a particular app, or a particular browser tab. This is a problem that I see in native apps often. At some video conference someone wants to share a slideshow, but they end up showing their mail inbox or other open documents that happen to be on screen at the same time. In fact, we could display a list of running apps/tabs and then add an entry for full screen. Then force the user to actively choose one of the options in the list before clicking a share appname button. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
Jonas, Le 24 oct. 2014 à 10:08, Jonas Sicking jo...@sicking.cc a écrit : It would also be cool to enable sharing just a particular app, or a particular browser tab. This is a problem that I see in native apps often. At some video conference someone wants to share a slideshow, but they end up showing their mail inbox or other open documents that happen to be on screen at the same time. Good point. I would like also to have in these cases that the history from URL bar doesn't display. It has the same kind of privacy implications. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
I think it would be useful to distinguish between a one-off screenshot and screen sharing/streaming here. On Thu, Oct 23, 2014 at 10:10 PM, Jet Villegas j...@mozilla.com wrote: 1. Web-facing or not? Both. Perhaps with different security models. 2. Security/Privacy concerns Many. If granting permission to take a screenshot, should it last for the duration of the session, or be something you explicitly ask the user for every time? A security model similar to camera might work for sharing the screen. 4. Feature requests (eg. blurred or lorem-ipsum text) We could have a hook to the API that allows manipulation of the element before the screenshot is taken, e.g. to transform text into lorem-ipsum or apply some CSS styling that blurs the text. But I'm not sure if there's such a strong use case for this? On Fri, Oct 24, 2014 at 8:48 AM, Anne van Kesteren ann...@annevk.nl wrote: 2) We could perhaps have some concept of taking a snapshot of the current page or indicated fragment so we can analyze it asynchronously. Then if a known-bad thing was found, such as a plugin, native form control, or non-CORS cross-origin image, we would reject. Capturing a fragment, e.g. the bounding box of an element, of the viewport seems useful, but what constitutes as “bad” in this context? It depends a lot on what the user wants to share. On Fri, Oct 24, 2014 at 9:08 AM, Jonas Sicking jo...@sicking.cc wrote: It would also be cool to enable sharing just a particular app, or a particular browser tab. Making this work on the visible portion of the document root element (viewport) by default of a single browser (content tab) makes a lot of sense, as there there are also privacy concerns with allowing a web-facing API to see the desktop. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On Fri, Oct 24, 2014 at 10:35 AM, Andreas Tolfsen a...@mozilla.com wrote: On Fri, Oct 24, 2014 at 8:48 AM, Anne van Kesteren ann...@annevk.nl wrote: 2) We could perhaps have some concept of taking a snapshot of the current page or indicated fragment so we can analyze it asynchronously. Then if a known-bad thing was found, such as a plugin, native form control, or non-CORS cross-origin image, we would reject. Capturing a fragment, e.g. the bounding box of an element, of the viewport seems useful, but what constitutes as “bad” in this context? It depends a lot on what the user wants to share. I had the original screenshot API in mind, which would expose the resulting pixels to the site's origin. Anything that does that either needs permission or needs to return nothing if something compromising the same-origin policy would be exposed otherwise. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Problem with batch logging
Hi,
I'm extending the Firefox source in order to log some information during web
app execution, for example event, script executions, new element creations,
removals, attribute modifications, etc. Since these things occur often, when I
load a more demanding application (e.g. facebook), everything hangs for a
while, because there is a large number of relatively small pieces of
information being written to a file.
Because of this, i was thinking of doing it in batches, having one global
extern stream variable where all longs are added to, and when enough
information gets accumulated to write it to a file, and avoid these hangings.
Since I'm a noob C++ programmer I will paste some code of what i've done,
just in case:
I have one header file with the extern variable:
-- FC_ExternStreamDeclaration.h --
#ifndef FC_EXTERN_VAR_DECL_H
#define FC_EXTERN_VAR_DECL_H
#include stdio.h
#include sstream
#include fstream
extern std::stringstream FC_LOG_STREAM;
#endif //FC_EXTERN_VAR_DECL_H
and one header with the logging functionality
-- FC_Log.h --
#pragma once
#ifndef FC_LOG_H
#define FC_LOG_H
#include stdio.h
#include sstream
#include fstream
#include FC_ExternStreamDeclaration.h
inline void WriteToStream(const char** fragments, int length)
{
//add to stream
//if stream big enough write to file
}
#endif //FC_LOG_H
and in nsBrowserApp.cpp where the main function is defined, i define the
variable and include the headers
- nsBrowserApp.cpp ---
#include FC_ExternStreamDeclaration.h
#include FC_Log.h
std::stringstream FC_LOG_STREAM;
And then, in each file from which i do logging, i include the header files and
call the WriteToStream function. For example, I'm doing it from
Interpreter.cpp, Eval.cpp, nsINode.h, etc. (all over the code).
And i thought that this will be enough. However, i get: error LNK2001
unresolved external symbol stringstream FC_LOG_STREAM. If i define it there,
the compilation succeeds, but I effectively get two different streams, one for
the JavaScript execution, and the other for the DOM and the rest of the browser.
I'm thinking this happens because these variables are in different dlls.
I would be grateful for any tips about fixing it.
Sorry for the long question.
Thank you,
Josip
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Changing our help messages to mention --foo options instead of -foo options
On 10/23/14 9:20 PM, Nicholas Nethercote wrote: Hello. Our command-line option handling is *interesting*. Did you know that: - our options work in -foo form and --foo form; - they are case-insensitive; - this holds for both short options (e.g. -h) and long options (e.g. -help). I did in fact know this, but I may be one of the few. This dates back to the pre-FF1.0 days where we had different startup paths for windows/mac/linux each of which had their own arg handling code with different expectations. My decision was to accept all the different varieties of argument and treat them equivalently. At least, all this is true for the options that are processed via the main option-processing code. Some of our options are handled elsewhere, via ad hoc code that is generally less flexible. Can you point me to this? Pretty much any code handling command lines should either be use the nsAppRunner code or using the nsICommandLine APIs. Before I land those patches, I thought I would ask here if anyone can see any reason not to do this. Remember, it's not a functional change -- both -foo and --foo options will still work -- it's just a documentation change. Doesn't matter to me. Another obvious follow-up is to drop support for -foo options, but that's *much* harder, so I haven't even bothered filing a bug about that. I don't think we should ever do this. It would break some existing user for no apparent benefit other that consistency with standard command-line conventions. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Problem with batch logging
Well, for one thing, never perform I/O on the main thread. It really
kills performance, as you witness. No amount of batching is going to be
sufficient.
Also, why don't you use our stream classes?
Cheers,
David
On 24/10/14 14:36, Josip Maras wrote:
Hi,
I'm extending the Firefox source in order to log some information during web
app execution, for example event, script executions, new element creations,
removals, attribute modifications, etc. Since these things occur often, when
I load a more demanding application (e.g. facebook), everything hangs for a
while, because there is a large number of relatively small pieces of
information being written to a file.
Because of this, i was thinking of doing it in batches, having one global
extern stream variable where all longs are added to, and when enough
information gets accumulated to write it to a file, and avoid these hangings.
Since I'm a noob C++ programmer I will paste some code of what i've done,
just in case:
I have one header file with the extern variable:
-- FC_ExternStreamDeclaration.h --
#ifndef FC_EXTERN_VAR_DECL_H
#define FC_EXTERN_VAR_DECL_H
#include stdio.h
#include sstream
#include fstream
extern std::stringstream FC_LOG_STREAM;
#endif //FC_EXTERN_VAR_DECL_H
and one header with the logging functionality
-- FC_Log.h --
#pragma once
#ifndef FC_LOG_H
#define FC_LOG_H
#include stdio.h
#include sstream
#include fstream
#include FC_ExternStreamDeclaration.h
inline void WriteToStream(const char** fragments, int length)
{
//add to stream
//if stream big enough write to file
}
#endif //FC_LOG_H
and in nsBrowserApp.cpp where the main function is defined, i define the
variable and include the headers
- nsBrowserApp.cpp ---
#include FC_ExternStreamDeclaration.h
#include FC_Log.h
std::stringstream FC_LOG_STREAM;
And then, in each file from which i do logging, i include the header files
and call the WriteToStream function. For example, I'm doing it from
Interpreter.cpp, Eval.cpp, nsINode.h, etc. (all over the code).
And i thought that this will be enough. However, i get: error LNK2001
unresolved external symbol stringstream FC_LOG_STREAM. If i define it there,
the compilation succeeds, but I effectively get two different streams, one
for the JavaScript execution, and the other for the DOM and the rest of the
browser.
I'm thinking this happens because these variables are in different dlls.
I would be grateful for any tips about fixing it.
Sorry for the long question.
Thank you,
Josip
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On 10/24/14, 3:48 AM, Anne van Kesteren wrote: Then if a known-bad thing was found, such as a plugin, native form control, or non-CORS cross-origin image, Or link, right? Otherwise you leak :visited state. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On Fri, Oct 24, 2014 at 4:56 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/24/14, 3:48 AM, Anne van Kesteren wrote: Then if a known-bad thing was found, such as a plugin, native form control, or non-CORS cross-origin image, Or link, right? Otherwise you leak :visited state. I was not trying to be exhaustive, but presumably you would render the copy as if nothing was visited. If that's not feasible, then sure. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MSE WebM/VP9 enabled on nightly
I just wanted to give a heads up to everyone that we enabled Media Source Extensions on nightly for WebM/VP9. This brings Adaptive Streaming capability to Firefox video playback. The feature is not complete so the pref will automatically turn off when it gets to beta/release if we do nothing. You can check on YouTube by right clicking the playing video and selecting Stats for nerds which should appear above the About the HTML5 player option. If you see DASH: yes then you are now living in the future. This affects YouTube but may also affect sites that use MSE with WebM/VP9 but it could also affect sites that use MSE but fail to check codec compatibility. Please file any (unfiled) issues you experience as blocking bug 1083588. Don't expect it to be perfect and if you run into trouble you can set media.mediasource.enabled to false in your about:config Anthony ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On 24/10/14 10:08, Jonas Sicking wrote: 2. Security/Privacy concerns so we'd have to be careful with how we do it. For example always showing an on-screen indicator indicating that the screen is currently shared. And reminding the user that password etc can be read by the remote party. And forcing the user to explicitly choose the option rather than just clicking a yes button (aka 'whatever button') might be a good idea. I guess, if to make sure that users are somewhat aware of what's going on, we could have something like the following process: 1. Change cursor to a camera; 2. Need to click on the window, or on a big Cancel button; 3. Shutter sound; 4. Preview of the picture, with the words Share/Cancel. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Win64 builds tests coming soon!
As of today we also have: * Win64 opt talos * Win64 pgo builds, tests and talos Both of them running on Windows 8 64-bit test machines. On graphs.m.o you should recognize the platform as WINNT 6.2 x64. cheers, Armen On 14-10-21 04:00 PM, Chris AtLee wrote: Hi, Just a quick note that we're hoping to enable 64-bit windows builds tests across most trunk branches this week. This includes branches such as mozilla-central, mozilla-inbound, fx-team, etc. In order to get adequate test coverage without at the same time overwhelming our windows test infrastructure, we've decided to disable 32-bit windows 8 testing on these branches and enable 64-bit windows 8 testing instead. Work is being tracked in bug 1080134 [1]. Please follow up there, or find me in #releng. Cheers, Chris [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1080134 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
Here is my writeup of the security issues with this from a while ago: http://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html As MT says, we already are shipping screen sharing in FF 33. It's currently whitelisted, but otherwise it's fairly complete. -Ekr On Fri, Oct 24, 2014 at 1:08 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Oct 23, 2014 at 2:10 PM, Jet Villegas j...@mozilla.com wrote: Kicking off this thread to get a discussion on: 1. Web-facing or not? I think we have to make it web facing. If we want the web to be competitive with other platforms, which I hope we do, we have to expose this functionality. However it definitely has a lot of 2. Security/Privacy concerns so we'd have to be careful with how we do it. For example always showing an on-screen indicator indicating that the screen is currently shared. And reminding the user that password etc can be read by the remote party. And forcing the user to explicitly choose the option rather than just clicking a yes button (aka 'whatever button') might be a good idea. It would also be cool to enable sharing just a particular app, or a particular browser tab. This is a problem that I see in native apps often. At some video conference someone wants to share a slideshow, but they end up showing their mail inbox or other open documents that happen to be on screen at the same time. In fact, we could display a list of running apps/tabs and then add an entry for full screen. Then force the user to actively choose one of the options in the list before clicking a share appname button. / 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: Screen Capture
Just in case this makes it into bugzilla, this is the bug that’s tracking the original proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=744100 -- - Milan On Oct 24, 2014, at 11:44 , Eric Rescorla e...@rtfm.com wrote: Here is my writeup of the security issues with this from a while ago: http://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html As MT says, we already are shipping screen sharing in FF 33. It's currently whitelisted, but otherwise it's fairly complete. -Ekr On Fri, Oct 24, 2014 at 1:08 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Oct 23, 2014 at 2:10 PM, Jet Villegas j...@mozilla.com wrote: Kicking off this thread to get a discussion on: 1. Web-facing or not? I think we have to make it web facing. If we want the web to be competitive with other platforms, which I hope we do, we have to expose this functionality. However it definitely has a lot of 2. Security/Privacy concerns so we'd have to be careful with how we do it. For example always showing an on-screen indicator indicating that the screen is currently shared. And reminding the user that password etc can be read by the remote party. And forcing the user to explicitly choose the option rather than just clicking a yes button (aka 'whatever button') might be a good idea. It would also be cool to enable sharing just a particular app, or a particular browser tab. This is a problem that I see in native apps often. At some video conference someone wants to share a slideshow, but they end up showing their mail inbox or other open documents that happen to be on screen at the same time. In fact, we could display a list of running apps/tabs and then add an entry for full screen. Then force the user to actively choose one of the options in the list before clicking a share appname button. / 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
Ah. So this seems to be a rather more limited function than the one that we are currently providing, which is a full motion video of the screen/window. I haven't decided yet whether I think it makes sense to have a snapshot API as a separate thing, as opposed to just capturing the video stream and taking a single frame out of it. -Ekr On Fri, Oct 24, 2014 at 9:13 AM, Milan Sreckovic msrecko...@mozilla.com wrote: Just in case this makes it into bugzilla, this is the bug that’s tracking the original proposal: https://bugzilla.mozilla.org/show_bug.cgi?id=744100 -- - Milan On Oct 24, 2014, at 11:44 , Eric Rescorla e...@rtfm.com wrote: Here is my writeup of the security issues with this from a while ago: http://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html As MT says, we already are shipping screen sharing in FF 33. It's currently whitelisted, but otherwise it's fairly complete. -Ekr On Fri, Oct 24, 2014 at 1:08 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Oct 23, 2014 at 2:10 PM, Jet Villegas j...@mozilla.com wrote: Kicking off this thread to get a discussion on: 1. Web-facing or not? I think we have to make it web facing. If we want the web to be competitive with other platforms, which I hope we do, we have to expose this functionality. However it definitely has a lot of 2. Security/Privacy concerns so we'd have to be careful with how we do it. For example always showing an on-screen indicator indicating that the screen is currently shared. And reminding the user that password etc can be read by the remote party. And forcing the user to explicitly choose the option rather than just clicking a yes button (aka 'whatever button') might be a good idea. It would also be cool to enable sharing just a particular app, or a particular browser tab. This is a problem that I see in native apps often. At some video conference someone wants to share a slideshow, but they end up showing their mail inbox or other open documents that happen to be on screen at the same time. In fact, we could display a list of running apps/tabs and then add an entry for full screen. Then force the user to actively choose one of the options in the list before clicking a share appname button. / 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing Eclipse CDT IDE Support
I believe for b2g you can use the following which will only rebuild gecko: cd objdir-gecko/ ../gecko/mach ide eclipse On Fri, Oct 24, 2014 at 12:22 AM, Botond Ballo bba...@mozilla.com wrote: A new command has now landed: './mach ide eclipse' Nice! Thanks for all your work on this. will perform the following: - Rebuild the project Does this work on B2G? Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On 2014-10-24 4:08 AM, Jonas Sicking wrote: On Thu, Oct 23, 2014 at 2:10 PM, Jet Villegas j...@mozilla.com wrote: Kicking off this thread to get a discussion on: 1. Web-facing or not? I think we have to make it web facing. If we want the web to be competitive with other platforms, which I hope we do, we have to expose this functionality. However it definitely has a lot of 2. Security/Privacy concerns so we'd have to be careful with how we do it. For example always showing an on-screen indicator indicating that the screen is currently shared. And reminding the user that password etc can be read by the remote party. And forcing the user to explicitly choose the option rather than just clicking a yes button (aka 'whatever button') might be a good idea. Can we keep track of where the stream comes from, and make sure to taint the images that can come out of them similar to the way that we taint cross origin images by default to prevent them from being read back on the client? I think with that, and a prompting similar to the camera prompting of getUserMedia, we may address a good chunk of these issues. (But admittedly I haven't thought very carefully about this yet.) It would also be cool to enable sharing just a particular app, or a particular browser tab. This is a problem that I see in native apps often. At some video conference someone wants to share a slideshow, but they end up showing their mail inbox or other open documents that happen to be on screen at the same time. In fact, we could display a list of running apps/tabs and then add an entry for full screen. Then force the user to actively choose one of the options in the list before clicking a share appname button. That sounds like a good idea. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Problem with batch logging
It's hard to determine exactly what's happening because your post
doesn't explain where you're using this variable, but note that extern
variables cannot be used across module boundaries. For example,
nsBrowserApp.cpp get compiled into firefox.exe, whereas most of our code
gets compiled in xul.dll. If you define an extern variable somewhere in
firefox.exe, you cannot use it from xul.dll. If you need this kind of
cross module access, you need to export a function/variable from one
module and import and call it in the other, using MOZ_EXPORT and
MOZ_IMPORT_API and friends.
On 2014-10-24 8:36 AM, Josip Maras wrote:
Hi,
I'm extending the Firefox source in order to log some information during web
app execution, for example event, script executions, new element creations,
removals, attribute modifications, etc. Since these things occur often, when I
load a more demanding application (e.g. facebook), everything hangs for a
while, because there is a large number of relatively small pieces of
information being written to a file.
Because of this, i was thinking of doing it in batches, having one global
extern stream variable where all longs are added to, and when enough
information gets accumulated to write it to a file, and avoid these hangings.
Since I'm a noob C++ programmer I will paste some code of what i've done,
just in case:
I have one header file with the extern variable:
-- FC_ExternStreamDeclaration.h --
#ifndef FC_EXTERN_VAR_DECL_H
#define FC_EXTERN_VAR_DECL_H
#include stdio.h
#include sstream
#include fstream
extern std::stringstream FC_LOG_STREAM;
#endif //FC_EXTERN_VAR_DECL_H
and one header with the logging functionality
-- FC_Log.h --
#pragma once
#ifndef FC_LOG_H
#define FC_LOG_H
#include stdio.h
#include sstream
#include fstream
#include FC_ExternStreamDeclaration.h
inline void WriteToStream(const char** fragments, int length)
{
//add to stream
//if stream big enough write to file
}
#endif //FC_LOG_H
and in nsBrowserApp.cpp where the main function is defined, i define the
variable and include the headers
- nsBrowserApp.cpp ---
#include FC_ExternStreamDeclaration.h
#include FC_Log.h
std::stringstream FC_LOG_STREAM;
And then, in each file from which i do logging, i include the header files and
call the WriteToStream function. For example, I'm doing it from
Interpreter.cpp, Eval.cpp, nsINode.h, etc. (all over the code).
And i thought that this will be enough. However, i get: error LNK2001
unresolved external symbol stringstream FC_LOG_STREAM. If i define it there,
the compilation succeeds, but I effectively get two different streams, one for
the JavaScript execution, and the other for the DOM and the rest of the browser.
I'm thinking this happens because these variables are in different dlls.
I would be grateful for any tips about fixing it.
Sorry for the long question.
Thank you,
Josip
___
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: Screen Capture
On Fri, Oct 24, 2014 at 8:48 PM, Anne van Kesteren ann...@annevk.nl wrote: 2) We could perhaps have some concept of taking a snapshot of the current page or indicated fragment so we can analyze it asynchronously. Then if a known-bad thing was found, such as a plugin, native form control, or non-CORS cross-origin image, we would reject. That way lies madness. There are too many ways cross-origin data can affect rendering. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On Sat, Oct 25, 2014 at 6:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Can we keep track of where the stream comes from, and make sure to taint the images that can come out of them similar to the way that we taint cross origin images by default to prevent them from being read back on the client? I think with that, and a prompting similar to the camera prompting of getUserMedia, we may address a good chunk of these issues. (But admittedly I haven't thought very carefully about this yet.) This is hard because normally you want to transmit these screenshots or sequence of screenshots somewhere. If an app is transmitting them, it can probably capture them at the other end. I guess a permissions approach with an always-on reminder that your screen is being captured can probably work. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On Fri, Oct 24, 2014 at 3:56 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Oct 25, 2014 at 6:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Can we keep track of where the stream comes from, and make sure to taint the images that can come out of them similar to the way that we taint cross origin images by default to prevent them from being read back on the client? I think with that, and a prompting similar to the camera prompting of getUserMedia, we may address a good chunk of these issues. (But admittedly I haven't thought very carefully about this yet.) This is hard because normally you want to transmit these screenshots or sequence of screenshots somewhere. If an app is transmitting them, it can probably capture them at the other end. I guess a permissions approach with an always-on reminder that your screen is being captured can probably work. Unfortunately, for the reasons I mentioned in the post I linked to above, it's hard for the user to give informed consent here, as they don't understand SOP, CSRF, etc. -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MSE WebM/VP9 enabled on nightly
On 2014/10/24 13:46, Anthony Jones wrote:
I just wanted to give a heads up to everyone that we enabled Media
Source Extensions on nightly for WebM/VP9. This brings Adaptive
Streaming capability to Firefox video playback. The feature is not
complete so the pref will automatically turn off when it gets to
beta/release if we do nothing.
You can check on YouTube by right clicking the playing video and
selecting Stats for nerds which should appear above the About the
HTML5 player option. If you see DASH: yes then you are now living in
the future.
This affects YouTube but may also affect sites that use MSE with
WebM/VP9 but it could also affect sites that use MSE but fail to check
codec compatibility.
Please file any (unfiled) issues you experience as blocking bug 1083588.
Don't expect it to be perfect and if you run into trouble you can set
media.mediasource.enabled to false in your about:config
Anthony
Hi,
Just reporting what I observed after a source refresh half a day ago.
I noticed during C-C TB compilation
a file under common needs to be copied to encoder, another one to
decoder directory .
I am talking about files below these directories.
mozilla/media/libvpx/vp9/{common,encoder,decoder}
But since C-C was in such a disarray in terms of compilation lately,
etc., and the source was refreshed just before this compilation effort,
I am not sure if the configuration was quite correct.
I failed to write down a memo exactly which files were
copied. I thought I was logging it using script, but did not.
I clobbered and then tried to see how it would work out, and then was
side-tracked by bug 1088497
I can compare the directory to report what files were copied
if no such bugs have been filed yet and you are not aware of the issue.
(I tried to see which one by timestamp, but python client.py checkout
seems to give same timestamps to all the files and so I am not sure
which ones were copied. cp or Emacs's filecopy seems to preserve the
timestamp. That is good sometimes, but annoying sometimes.)
But then again, I am not entirely sure if it was a temporal hiccup after
the source refresh.
Just an observation.
TIA
TIA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Screen Capture
On Fri, Oct 24, 2014 at 9:25 PM, Eric Rescorla e...@rtfm.com wrote: On Fri, Oct 24, 2014 at 3:56 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Oct 25, 2014 at 6:17 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Can we keep track of where the stream comes from, and make sure to taint the images that can come out of them similar to the way that we taint cross origin images by default to prevent them from being read back on the client? I think with that, and a prompting similar to the camera prompting of getUserMedia, we may address a good chunk of these issues. (But admittedly I haven't thought very carefully about this yet.) This is hard because normally you want to transmit these screenshots or sequence of screenshots somewhere. If an app is transmitting them, it can probably capture them at the other end. I guess a permissions approach with an always-on reminder that your screen is being captured can probably work. Unfortunately, for the reasons I mentioned in the post I linked to above, it's hard for the user to give informed consent here, as they don't understand SOP, CSRF, etc. It's unclear to me what you are suggesting that we should or should not do. Also, often times there's much more sensitive information captured from a user's camera, than from a user's screen. Doesn't SOP and CSRF concerns apply there too? / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
