Re: Embeddable Browser

[段垚]

For extended support (non-offical) of xulrunner-stub, see my project: 
https://github.com/duanyao/xulrunner-stub


For embedable gecko in Winforms, see GeckoFX: https://bitbucket.org/geckofx/


在 2017/2/20 18:38, Rodolpho Porto 写道:

Hello guys,

I do not know if this serious or the right group to do this ask, but I will try 
here rss

Xulrunner no longer has updates, where do I find information or documentation 
from a substitute for it? I am currently researching information about Gecko 
and Firefox to set up an embeddable browser to replace what I did with 
Xulrunner, but I find little information, can anyone give me a light on this?

Thank you: D
___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

Seems I failed to convince you to change the plan.

So the last question is: when will this happen?


在 2017/2/15 2:54, Till Schneidereit 写道:

On Tue, Feb 14, 2017 at 12:00 PM, 段垚 <duan...@ustc.edu> wrote:



在 2017/2/14 18:10, Till Schneidereit 写道:


On Tue, Feb 14, 2017 at 12:14 AM, 段垚 <duan...@ustc.edu> wrote:

I guess all popular softwares have exploits being traded. How this fact

invalidates my argument?

I was responding to your point about the threat declining because of

the
declining usage of Flash.  This is demonstrably not true.

Why? Assume

  threat_of_flash = exploits_of_flash_per_year *
usage_of_flash_per_year

If usage_of_flash_per_year is declining but threat_of_flash is
increasing,
then exploits_of_flash_per_year must be increasing.
But the report you cited does not provide such data.

That assumption doesn't hold: malicious uses of Flash don't need

non-malicious ones.


I agree. So let me ask this question instead: is there any proof that
local-only Flash
exploits are increasing?


I don't know. I do know that legitimate usage of Flash, be it via file: or
otherwise, is steadily declining. That's all that's needed to change the
cost/benefit balance here.



In fact it seems quite likely that there'll be an inverse relationship:
less (non-malicious) usage means less testing of potentially exploitable
code paths, which would increase the threat.


I would assume Adobe will actively test Flash plugin with local contents
for a reasonablely long time. Do you mean tests in Firefox for local Flash
contents
will inevitably decrease even if you don't disable it?


What I'm saying is that testing and hardening against attacks isn't free,
so requires investing resources. This entire thread is based on the
conclusion that Flash usage has diminished to a point where it's can no
longer a good investment of resources to keep doing these activities for
this fairly niche-usage of Flash.



One solution to this is to decouple the amount of testing done for those
code paths from how frequently they're used. In practice that's not
trivial
because at least some testing comes in the form of investigating crash
reports from users. Another solution is what's proposed here: disable
less-well tested configurations altogether.


Also I think forbidding non-http(s) Flash does not fix thoses exploits

magically.

Sure, this is about reducing attack surface, not completely eliminating

it.

Non-http(s) Flash takes only a small fraction of all Flash contents,

even
for users who do use non-http(s) Flash.
I don't think users want to drop their local Flash for a small fraction
of
reduced attack surface,
especially if those local Flash don't have alternatives yet. The more
practical reaction is trying another browser.


The underlying assumption here is that these usages of Flash are rare
enough that the incompatibility, while unfortunate, becomes acceptable.
Note that other browser vendors are planning their own measures for
restricting Flash usage, too.


Although usage of local Flash is rare, I'd point out that local Flash
contents usually have higher
value than those on web sites, Because users only save important contents
to disks.
Additionally, local Flash contents are much harder to replace than those
on web sites
because users can hardly contact the author. Please consider more for
users.


We are doing precisely that, but we believe that our users are better
served by us investing resources in tasks that have more impact. Again, the
underlying assumption in this entire thread is that our users won't be
affected as strongly as you assume, or few enough 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: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/14 18:10, Till Schneidereit 写道:

On Tue, Feb 14, 2017 at 12:14 AM, 段垚 <duan...@ustc.edu> wrote:


I guess all popular softwares have exploits being traded. How this fact

invalidates my argument?


I was responding to your point about the threat declining because of the
declining usage of Flash.  This is demonstrably not true.


Why? Assume

 threat_of_flash = exploits_of_flash_per_year * usage_of_flash_per_year

If usage_of_flash_per_year is declining but threat_of_flash is increasing,
then exploits_of_flash_per_year must be increasing.
But the report you cited does not provide such data.


That assumption doesn't hold: malicious uses of Flash don't need
non-malicious ones.
I agree. So let me ask this question instead: is there any proof that 
local-only Flash

exploits are increasing?



In fact it seems quite likely that there'll be an inverse relationship:
less (non-malicious) usage means less testing of potentially exploitable
code paths, which would increase the threat.


I would assume Adobe will actively test Flash plugin with local contents
for a reasonablely long time. Do you mean tests in Firefox for local 
Flash contents

will inevitably decrease even if you don't disable it?



One solution to this is to decouple the amount of testing done for those
code paths from how frequently they're used. In practice that's not trivial
because at least some testing comes in the form of investigating crash
reports from users. Another solution is what's proposed here: disable
less-well tested configurations altogether.



Also I think forbidding non-http(s) Flash does not fix thoses exploits

magically.


Sure, this is about reducing attack surface, not completely eliminating
it.


Non-http(s) Flash takes only a small fraction of all Flash contents, even
for users who do use non-http(s) Flash.
I don't think users want to drop their local Flash for a small fraction of
reduced attack surface,
especially if those local Flash don't have alternatives yet. The more
practical reaction is trying another browser.


The underlying assumption here is that these usages of Flash are rare
enough that the incompatibility, while unfortunate, becomes acceptable.
Note that other browser vendors are planning their own measures for
restricting Flash usage, too.


Although usage of local Flash is rare, I'd point out that local Flash 
contents usually have higher
value than those on web sites, Because users only save important 
contents to disks.
Additionally, local Flash contents are much harder to replace than those 
on web sites

because users can hardly contact the author. Please consider more for users.



I understand that none of this helps you, and that's very unfortunate. I
hope you appreciate that we don't have infinite resources and thus have to
make, sometimes painful, trade-offs. Much as you probably have to in your
own projects.
___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/14 2:03, Ehsan Akhgari 写道:

On 2017-02-13 11:50 AM, 段垚 wrote:


在 2017/2/14 0:24, Ehsan Akhgari 写道:

On 2017-02-10 7:51 PM, 段垚 wrote:

在 2017/2/11 2:26, t...@ritter.vg 写道:

On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg  wrote:

I thought I enumerated the harm at first, but I'll elaborate a little.

1) Flash doesn't know about and breaks our "current and subdirectory
only"
file: origin policy.

2) Flash is a high-risk attack surface: if you can get somebody to
download
a SWF they can probably own your system. We don't have anyone
testing or
defending this effectively.

So we believe that there is significant harm in the current
situation, and
very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A
malicious flash applet open opened from file:// can read the user's
profile, take all their saved passwords, cookies, etc and steal data,
masquerade as them, and perform all manner of malicious activity.

I agree that this is a problem, but I disagree that Firefox must remove
this behavior now.

* This behavior has existed for decades in all desktop browsers, and the
usage of Flash is declining, which means the threaten is also declining.

That is not true.  It is public knowledge that Flash exploits are traded
as a commodity these days:
<https://www.wired.com/2015/07/hacking-team-leak-shows-secretive-zero-day-exploit-sales-work/>.


I guess all popular softwares have exploits being traded. How this fact
invalidates my argument?

I was responding to your point about the threat declining because of the
declining usage of Flash.  This is demonstrably not true.


Why? Assume

threat_of_flash = exploits_of_flash_per_year * usage_of_flash_per_year

If usage_of_flash_per_year is declining but threat_of_flash is 
increasing, then exploits_of_flash_per_year must be increasing.

But the report you cited does not provide such data.




Also I think forbidding non-http(s) Flash does not fix thoses exploits
magically.

Sure, this is about reducing attack surface, not completely eliminating it.


Non-http(s) Flash takes only a small fraction of all Flash contents, 
even for users who do use non-http(s) Flash.
I don't think users want to drop their local Flash for a small fraction 
of reduced attack surface,
especially if those local Flash don't have alternatives yet. The more 
practical reaction is trying another browser.



___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/14 0:24, Ehsan Akhgari 写道:

On 2017-02-10 7:51 PM, 段垚 wrote:


在 2017/2/11 2:26, t...@ritter.vg 写道:

On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg  wrote:

I thought I enumerated the harm at first, but I'll elaborate a little.

1) Flash doesn't know about and breaks our "current and subdirectory
only"
file: origin policy.

2) Flash is a high-risk attack surface: if you can get somebody to
download
a SWF they can probably own your system. We don't have anyone testing or
defending this effectively.

So we believe that there is significant harm in the current
situation, and
very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A
malicious flash applet open opened from file:// can read the user's
profile, take all their saved passwords, cookies, etc and steal data,
masquerade as them, and perform all manner of malicious activity.

I agree that this is a problem, but I disagree that Firefox must remove
this behavior now.

* This behavior has existed for decades in all desktop browsers, and the
usage of Flash is declining, which means the threaten is also declining.

That is not true.  It is public knowledge that Flash exploits are traded
as a commodity these days:
<https://www.wired.com/2015/07/hacking-team-leak-shows-secretive-zero-day-exploit-sales-work/>.


I guess all popular softwares have exploits being traded. How this fact 
invalidates my argument?
Also I think forbidding non-http(s) Flash does not fix thoses exploits 
magically.



___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/11 2:26, t...@ritter.vg 写道:

On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg  wrote:

I thought I enumerated the harm at first, but I'll elaborate a little.

1) Flash doesn't know about and breaks our "current and subdirectory only"
file: origin policy.

2) Flash is a high-risk attack surface: if you can get somebody to download
a SWF they can probably own your system. We don't have anyone testing or
defending this effectively.

So we believe that there is significant harm in the current situation, and
very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A malicious 
flash applet open opened from file:// can read the user's profile, take all 
their saved passwords, cookies, etc and steal data, masquerade as them, and 
perform all manner of malicious activity.


I agree that this is a problem, but I disagree that Firefox must remove 
this behavior now.


* This behavior has existed for decades in all desktop browsers, and the 
usage of Flash is declining, which means the threaten is also declining.

So I don't see the reason for an immediate removal.

* Flash plugin is still actively maintained by Adobe, so I think you can 
ask them to restrict permissions for local Flash contents.

This would benifit all browsers, not just Firefox.



-tom
___
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 implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/10 22:34, Benjamin Smedberg 写道:

On Fri, Feb 10, 2017 at 12:36 AM, 段垚 <duan...@ustc.edu> wrote:


在 2017/2/10 1:28, Benjamin Smedberg 写道:


On Wed, Feb 8, 2017 at 2:26 AM, 段垚 <duan...@ustc.edu> wrote:

Is this just preventing auto-loading (like "click to play") or completely

disable Flash for non-http(s) contents?

This is completely disabling this content.


Can users get back old behavior by flipping a preference?

That is not the plan, no.

Well, this plan seems too aggressive. I'd rather recommend implementing

"click to play" for non-http(s) Flash first and deferring complete removal.

IE requires user's confirmation to load local Flash for a long time.


We are planning on making Flash click-to-play by default for all content.
However, our implementation of click-to-play is based on remembering that
setting per site. This implementation does not work with file: URIs and the
engineering and QA effort to make it work is well beyond what we think is a
reasonable investment.


I think it is OK to not remember that setting for file-urls - just 
require confirmation on each reload.

Is this simpler to implementation?


Flash is a dying technology and this is one low-cost
way we can reduce attack surface and make users safer.

--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: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

在 2017/2/10 1:28, Benjamin Smedberg 写道:

On Wed, Feb 8, 2017 at 2:26 AM, 段垚 <duan...@ustc.edu> wrote:


Is this just preventing auto-loading (like "click to play") or completely
disable Flash for non-http(s) contents?


This is completely disabling this content.



Can users get back old behavior by flipping a preference?


That is not the plan, no.

Well, this plan seems too aggressive. I'd rather recommend implementing 
"click to play" for non-http(s) Flash first and deferring complete removal.


IE requires user's confirmation to load local Flash for a long time.


We have developed a Firefox based tool to edit/view local EPub files,
which may contain Flash.

If this feature can't be opt-out , we and our customs will be in trouble.


My mind is filled with questions about how epub+Flash could ever be a good
idea, but I will avoid asking them here.
Epub+Flash is not quite a good idea, it is just because our Flash assets 
can't be replaced in a short term.



Instead, could you work around
this by serving the content and loading it from http://localhost ? That is
what we intend to recommend for developers building Flash websites and
wanting to test locally.
Local http server could trigger security alarm of OS/firewall, which 
confuses users: why a desktop app want to start a server?


Also local http server may be more insecure than direct file access, 
e.g. misconfigured or flawed server may allow

anyone on the net to access your files. So I'd rather not head to this way.


Otherwise, you will have to build your own builds with this restriction
removed.

--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: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[段垚]

Is this just preventing auto-loading (like "click to play") or 
completely disable Flash for non-http(s) contents?


Can users get back old behavior by flipping a preference?

We have developed a Firefox based tool to edit/view local EPub files, 
which may contain Flash.


If this feature can't be opt-out , we and our customs will be in trouble.

I understand and appreciate the trend of web without plugins, but we and 
our customs just have too many Flash assets.


Thanks.

Duan, Yao

在 2017/2/8 5:15, Benjamin Smedberg 写道:

I intend to ship a change which will prevent Flash from loading from file:,
ftp:, or any other URL scheme other than http: or https:.  The purpose of
this change is to increase security and limit Flash to well-tested
configuraitons.


- file: same-origin security mechanism is different, and so there have
been problems in the past with Flash content bypassing normal controls.
- Flash is normally not tested with ftp: or other protocols, and we've
had security issues in the past as a result of interactions between Flash
and these sites.

I am not yet sure whether we will be able to prevent Flash from loading in
data: contexts or not. I'd like to, but it may not be possible without
breaking existing content.
This work is being tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1335475

--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: Is it possible to implement "click to play" for Adobe Flash in XULRunner app?

[段垚]

Thank you very much!

It looks a bit complicated. Maybe I'd consider a pure front-end solution 
instead.



在 2017/1/14 0:06, Benjamin Smedberg 写道:
You have to manage the UI yourself. Firefox does this with a 
combination of applying an overlay to the disabled Flash which shows 
the grey UI, plus script that sets permissions and activates plugins 
appropriately. Because of e10s, that code is split between multiple 
files, but you should try to read and understand the following bits:


http://searchfox.org/mozilla-central/source/browser/modules/PluginContent.jsm 
- frame script (runs in content process)
http://searchfox.org/mozilla-central/source/browser/base/content/browser-plugins.js 
- UI script (runs in chrome process)
Binding files that set up the click-to-play overlay UI: 
http://searchfox.org/mozilla-central/source/toolkit/pluginproblem/content


Be aware that we're actively removing plugin support from the Mozilla 
platform; soon only Flash is likely to work, and after a while NPAPI 
might be removed completely. So don't get too wedded to plugin support 
in XULRunner as a long-term strategy.


--BDS


On Wed, Jan 11, 2017 at 10:01 PM, 段垚 <duan...@ustc.edu 
<mailto:duan...@ustc.edu>> wrote:


Hi,

In Firefox, "click to play" can be enabled by setting pref
"plugin.state.flash" to 1.

However, when I do this in a XULRunner app, flash plugin is
disabled completely.

Is this feature unavailable to XULRunner? If so, how can I
implement it?


Thanks.


Duan Yao.


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




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

Is it possible to implement "click to play" for Adobe Flash in XULRunner app?

[段垚]

Hi,

In Firefox, "click to play" can be enabled by setting pref 
"plugin.state.flash" to 1.


However, when I do this in a XULRunner app, flash plugin is disabled 
completely.


Is this feature unavailable to XULRunner? If so, how can I implement it?


Thanks.


Duan Yao.


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

Re: File() constructor with a string argument no longer works since Firefox 52a?

[段垚]

I see. Thank you very much!


在 2016/11/23 15:24, Shih-Chiang Chien 写道:

use File.createFromFileName(path)
see https://dxr.mozilla.org/mozilla-central/source/dom/webidl/File.webidl#48

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Wed, Nov 23, 2016 at 3:18 PM, 段垚 <duan...@ustc.edu> wrote:


Thanks. So the chrome-only constructor was removed. Is there an
alternative way to create a File object from a path?



在 2016/11/23 14:04, Kris Maglione 写道:


See https://bugzil.la/1303518

On Wed, Nov 23, 2016 at 01:48:43PM +0800, 段垚 wrote:


Hi,

In Firefox 51 chrome code, this code works: `new File(path_to_file)` ,
if  `path_to_file` exists.

However in Firefox 52a (2016-11-22)，an execption is thrown: "TypeError:
Not enough arguments to File".

I don't see a deprecation or removing note in the dev-doc[1], what's the
problem?

Thanks.


[1] https://developer.mozilla.org/en-US/docs/Extensions/Using_th
e_DOM_File_API_in_chrome_code


___
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: File() constructor with a string argument no longer works since Firefox 52a?

[段垚]

Thanks. So the chrome-only constructor was removed. Is there an 
alternative way to create a File object from a path?



在 2016/11/23 14:04, Kris Maglione 写道:

See https://bugzil.la/1303518

On Wed, Nov 23, 2016 at 01:48:43PM +0800, 段垚 wrote:

Hi,

In Firefox 51 chrome code, this code works: `new File(path_to_file)` 
, if  `path_to_file` exists.


However in Firefox 52a (2016-11-22)，an execption is thrown: 
"TypeError: Not enough arguments to File".


I don't see a deprecation or removing note in the dev-doc[1], what's 
the problem?


Thanks.


[1] 
https://developer.mozilla.org/en-US/docs/Extensions/Using_the_DOM_File_API_in_chrome_code

___
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

File() constructor with a string argument no longer works since Firefox 52a?

[段垚]

Hi,

In Firefox 51 chrome code, this code works: `new File(path_to_file)` , 
if  `path_to_file` exists.


However in Firefox 52a (2016-11-22)，an execption is thrown: "TypeError: 
Not enough arguments to File".


I don't see a deprecation or removing note in the dev-doc[1], what's the 
problem?


Thanks.


[1] 
https://developer.mozilla.org/en-US/docs/Extensions/Using_the_DOM_File_API_in_chrome_code



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

Re: XULRunner future and ownership

[段垚]

Hi,

For those who are still interested in XULRunner, I created a project to 
maintain the source of xulrunner-stub, and build against Firefox SDK. 
Here is the link:

https://github.com/duanyao/xulrunner-stub

Currently only win32 is supported, and Firefox 47a2 is tested.

I'd like to ask Mozilla people: will this route work for next 2 or 3 years?

在 2016/2/22 15:28, m.bauermeis...@sto.com 写道:

Is building the runtime manually still an option? If so, how would I go about 
it? Are the relevant sources all merged into the Firefox repository?
___
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: XULRunner future and ownership

[段垚]

Hi,

For those who are still interested in XULRunner, I created a project to 
maintain the source of xulrunner-stub, and build against Firefox SDK. 
Here is the link:

https://github.com/duanyao/xulrunner-stub

Currently only win32 is supported, and Firefox 47a2 is tested.

I'd like to ask Mozilla people: will this route work for the next 2 or 3 
years?


在 2016/2/22 15:28, m.bauermeis...@sto.com 写道:

Is building the runtime manually still an option? If so, how would I go about 
it? Are the relevant sources all merged into the Firefox repository?
___
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: XULRunner future and ownership

[段垚]

Hi,

For those who are still interested in XULRunner (especially the stub), I 
created a project to continue to build xulrunner-stub with Firefox SDK. 
Here is the link:

https://github.com/duanyao/xulrunner-stub .

I extracted xulrunner/stub/nsXULStub.cpp, xpcom/build/nsXPCOMPrivate.h , 
toolkit/xre/nsWindowsWMain.cpp and build them with Firefox SDK, and it seems
to work well. However, I'd like to ask Mozilla pepole: will this route 
keep feasible in the coming 2-3 years?


在 2016/2/22 15:28, m.bauermeis...@sto.com 写道:

Is building the runtime manually still an option? If so, how would I go about 
it? Are the relevant sources all merged into the Firefox repository?
___
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: HTML-based chrome and

[段垚]

在 2016/2/27 1:55, Myk Melez 写道:

Benjamin Francis 
2016 February 26 at 05:15
I mainly propose the change of syntax because this transition period 
seems
like an opportunity to make a clean break, get rid of the vendor 
prefixes
and define a long term, explicitly separate to standard HTML, 
chrome-only

solution with a cleaner API and without having to worry about backwards
compatibility because the mozBrowser API could exist in parallel 
until we

phase it out.
I'd like to see this too, if only because  is more ergonomic 
and easier to distinguish from the existing  API. 
However, the isolated  from bug 1238160 is 
reasonable and a great start.


But I think a more important piece than webview is the ability to 
execute a
Gecko-based user agent with HTML-based chrome without having to run 
it on

top of the Firefox binary.
I like this idea in theory. But I want to understand how it's 
different from Electron, besides simply using different underlying 
technology. In other words: what makes it unique that justifies the 
effort? Is there something that Gecko can provide that Chromium cannot 
(or is unlikely to)? Are there parts of the Electron stack that are 
encumbered in some way? Are there architectural choices that make 
Electron unsuitable or suboptimal for valuable use cases?


One of our project switched from Electron to XULRunner about half a year 
ago, because:


* MathML. Our project is a slide editor for education, so MathML is 
important. Google rejected to implement MathML so Electron and NW.js are 
out of luck.
  We tried to use mathml.css in Electron but you know the result is 
suboptimal. MathJax is suitable for presenting but not for editing.


* Auto update. We found that build-in auto updating of XULRunner is easy 
to use and robust. Electron and NW.js has no such mature solution yet.


* Windows XP support. Our project has to support XP for an extended 
time, however Chromium will drop XP support this year, and Electron 
never runs on XP.


Unfortunately, we might be force to switch back to Electron or NW.js in 
future because XULRunner was remove from Mozilla's code base and there 
is no foreseen alternative.
Our company is small and has not enough resource to maitain XULRunner by 
ourselves (We even don't known whether it is tecnically feasible). A 
HTML-based "XULRunner successor" is definitely interesting to us!




(You can argue that developers having two options is by itself 
beneficial. And I agree, in general. But I'm not yet convinced that we 
should therefore invest the effort to build the second option.)



If we no longer have XULRunner, if mozApps is
phased out and B2G loses platform support we're really running out of
options for how to use Gecko for non-Firefox projects. At what point 
does

the platform stop being a platform and just becomes Firefox?
That point is well in the past, as Gecko development post-Netscape has 
focused on the Web platform and integration with Firefox. Other uses, 
like XULRunner and embedding in native apps, have been second-class 
citizens, at best.



How are we
promoting innovation if we're effectively forcing alternative user 
agents

to use WebKit?
Mozilla's mission is to promote "openness, innovation & opportunity on 
the Web."  Mitchell clarified in 2007 that Mozilla's key platform is 
the Open Web 
.


I happen to think that making Gecko a great platform for building 
products like (but not limited to) Firefox indirectly benefits that 
mission. But doing so would still be in service to that mission, a way 
to help fulfill it, and not the actual mission itself.


-myk

___
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