Gecko - Firefox - security/feature updates

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Gecko - Firefox - security/feature updates

Wolfgang Rosenauer-2
Hi,

I almost missed the information about the plan to ship "features" in
patch level updates of Firefox instead only security stability stuff.

As this decision does not only affect Firefox within the most Linux
distributions I'm raising it in this more general group.

Many Linux distributions are currently shipping Firefox as a combination
of xulrunner and firefox for various reasons. The important thing is
that on Linux quite some applications use xulrunner (or only its gtk
embedding widget). With the security and stability patch level updates
that usually worked quite well. With feature updates I'm expecting API
breakage and xul incompatibilities to happen commonly.

I wonder what or if MoCo has any idea how that should work?

I somehow can see Linux distributions being stuck with an older version
of Firefox to keep API compatibility but missing security fixes. Or if
they update Firefox they have to keep an insecure xulrunner around for
the embedding stuff. While that solves the issue for Firefox it's still
some components which are not fixable security wise.

Any feedback?

Wolfgang
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Mike Beltzner
On 2010-01-18, at 6:00 AM, Wolfgang Rosenauer wrote:

> I almost missed the information about the plan to ship "features" in
> patch level updates of Firefox instead only security stability stuff.

That's because until now it's been an idea that a few people have been batting around in IRC and development meetings. We haven't really been discussing it broadly until we can fully determine what the shape of such releases would be and what all the impacts are. You're here at the right part of the conversation,

> Many Linux distributions are currently shipping Firefox as a combination
> of xulrunner and firefox for various reasons. The important thing is
> that on Linux quite some applications use xulrunner (or only its gtk
> embedding widget). With the security and stability patch level updates
> that usually worked quite well. With feature updates I'm expecting API
> breakage and xul incompatibilities to happen commonly.

That's a misplaced expectation. The work that we'd port back to branches would not break APIs or XUL compatibility; nothing that could impact platform-application compatibility. We can't ship an update which would result in Add-ons or other downstream contributors from working properly. As I understand it, that would include the case you're describing.

The types of features we're planning on delivering this way are:

 - additive web compatibilities (new API support, additional functionality for things like @font-face)
 - bug fixes (not just security fixes, but polish and correctness)
 - speed and stability improvements (not just security fixes, but things like OOPP as well)

> I wonder what or if MoCo has any idea how that should work?

Please note that is not a "MoCo" only initiative, unless that's short for "Mozilla Core Developer Group" which further means "the group of people who focus primarily on the development of Gecko and Firefox." While many of us work for the Mozilla Corporation, that's not how we decide who's got the best ideas. :)

> I somehow can see Linux distributions being stuck with an older version
> of Firefox to keep API compatibility but missing security fixes. Or if
> they update Firefox they have to keep an insecure xulrunner around for
> the embedding stuff. While that solves the issue for Firefox it's still
> some components which are not fixable security wise.

One question for you: are Linux distributions currently updating xulrunner now off of security releases such as 1.9.1.8?

cheers,
mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

SmauG-2
In reply to this post by Wolfgang Rosenauer-2
On 1/18/10 1:00 PM, Wolfgang Rosenauer wrote:

> Hi,
>
> I almost missed the information about the plan to ship "features" in
> patch level updates of Firefox instead only security stability stuff.
>
> As this decision does not only affect Firefox within the most Linux
> distributions I'm raising it in this more general group.
>
> Many Linux distributions are currently shipping Firefox as a combination
> of xulrunner and firefox for various reasons. The important thing is
> that on Linux quite some applications use xulrunner (or only its gtk
> embedding widget). With the security and stability patch level updates
> that usually worked quite well. With feature updates I'm expecting API
> breakage and xul incompatibilities to happen commonly.
>
> I wonder what or if MoCo has any idea how that should work?
>
> I somehow can see Linux distributions being stuck with an older version
> of Firefox to keep API compatibility but missing security fixes. Or if
> they update Firefox they have to keep an insecure xulrunner around for
> the embedding stuff. While that solves the issue for Firefox it's still
> some components which are not fixable security wise.
>
> Any feedback?
>
> Wolfgang

As a developer it would be great to know what problems API breakage has
caused and whether those problems could be solved easily.
In the code areas I work with I've seen very few bug comments (if any)
from linux distribution folks. Maybe the problems have been in other
modules.



-Olli
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Wolfgang Rosenauer-2
In reply to this post by Wolfgang Rosenauer-2
On 01/18/2010 02:04 PM, Mike Beltzner wrote:
> On 2010-01-18, at 6:00 AM, Wolfgang Rosenauer wrote:
>
>> I almost missed the information about the plan to ship "features" in
>> patch level updates of Firefox instead only security stability stuff.
>
> That's because until now it's been an idea that a few people have been batting around in IRC and development meetings. We haven't really been discussing it broadly until we can fully determine what the shape of such releases would be and what all the impacts are. You're here at the right part of the conversation,

Ok, some german online newsletter thing took it as fact with a reference
to computerworld.com.

>> Many Linux distributions are currently shipping Firefox as a combination
>> of xulrunner and firefox for various reasons. The important thing is
>> that on Linux quite some applications use xulrunner (or only its gtk
>> embedding widget). With the security and stability patch level updates
>> that usually worked quite well. With feature updates I'm expecting API
>> breakage and xul incompatibilities to happen commonly.
>
> That's a misplaced expectation. The work that we'd port back to branches would not break APIs or XUL compatibility; nothing that could impact platform-application compatibility. We can't ship an update which would result in Add-ons or other downstream contributors from working properly. As I understand it, that would include the case you're describing.
>
> The types of features we're planning on delivering this way are:
>
>  - additive web compatibilities (new API support, additional functionality for things like @font-face)
>  - bug fixes (not just security fixes, but polish and correctness)
>  - speed and stability improvements (not just security fixes, but things like OOPP as well)

That sounds much better then. Still it might be too many changes for
some Linux vendors.

>> I wonder what or if MoCo has any idea how that should work?
>
> Please note that is not a "MoCo" only initiative, unless that's short for "Mozilla Core Developer Group" which further means "the group of people who focus primarily on the development of Gecko and Firefox." While many of us work for the Mozilla Corporation, that's not how we decide who's got the best ideas. :)

Firefox still _is_ a MoCo product so the final decision is done there as
I understood.

>> I somehow can see Linux distributions being stuck with an older version
>> of Firefox to keep API compatibility but missing security fixes. Or if
>> they update Firefox they have to keep an insecure xulrunner around for
>> the embedding stuff. While that solves the issue for Firefox it's still
>> some components which are not fixable security wise.
>
> One question for you: are Linux distributions currently updating xulrunner now off of security releases such as 1.9.1.8?

I can only speak informed for openSUSE and yes, we are doing usually
doing every security update within a stable branch with Firefox and
xulrunner kept in sync. And afaics that's the same for the other popular
distros.


Wolfgang
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Wolfgang Rosenauer-2
In reply to this post by SmauG-2
On 01/18/2010 02:05 PM, Smaug wrote:
> As a developer it would be great to know what problems API breakage has
> caused and whether those problems could be solved easily.
> In the code areas I work with I've seen very few bug comments (if any)
> from linux distribution folks. Maybe the problems have been in other
> modules.

Hmm, not quite sure what you mean. There are indeed not really api
changes within a stable branch. But building stuff against
xulrunner.next always required changes to downstream users in the past.
I take most changes as given and try to fix or workaround them in
consumers so there are not many comments or bugreports expected.
Probably in some cases these issues are covered early from the original
projects and not from the distribution folks.

Wolfgang
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Mike Beltzner
In reply to this post by Wolfgang Rosenauer-2
On 2010-01-18, at 8:16 AM, Wolfgang Rosenauer wrote:

> Ok, some german online newsletter thing took it as fact with a reference
> to computerworld.com.

Yes, sadly I must report that things may not always be as they seem within the press. I wrote to Planet Mozilla late last week to try and clarify - this is a common danger when you have the attention that Firefox does and a policy to do all your planning and design in plain view:

http://beltzner.ca/mike/2010/01/15/of-rumours-and-broken-telephones/

> That sounds much better then. Still it might be too many changes for
> some Linux vendors.

Do you have specific examples of what you would consider to be too many changes?

>>> I wonder what or if MoCo has any idea how that should work?
>>
>> Please note that is not a "MoCo" only initiative, unless that's short for "Mozilla Core Developer Group" which further means "the group of people who focus primarily on the development of Gecko and Firefox." While many of us work for the Mozilla Corporation, that's not how we decide who's got the best ideas. :)
>
> Firefox still _is_ a MoCo product so the final decision is done there as
> I understood.

That's true, the trademark rests with the Corporation, but the procedures by which these decisions are made still fall within Mozilla Project governance.

> I can only speak informed for openSUSE and yes, we are doing usually
> doing every security update within a stable branch with Firefox and
> xulrunner kept in sync. And afaics that's the same for the other popular
> distros.

Good to know; there was recently a question about whether or not we needed to do nightly builds for xulrunner - any input there?

cheers,
mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Robert Kaiser
In reply to this post by Wolfgang Rosenauer-2
Mike Beltzner wrote:
> On 2010-01-18, at 8:16 AM, Wolfgang Rosenauer wrote:
>> Firefox still _is_ a MoCo product so the final decision is done there as
>> I understood.
>
> That's true, the trademark rests with the Corporation, but the procedures by which these decisions are made still fall within Mozilla Project governance.

Not wanting to split hairs here, but isn't the trademark with the
Foundation actually and Corporation making the product decisions? ;-)

At least that's how I understand it - though, of course, discussions are
much broader, but the decision making needs to be concentrated
somewhere. Though I could easily be wrong and it's a democratic project
now. :P

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Mike Beltzner
On 2010-01-18, at 8:51 AM, Robert Kaiser wrote:

> Mike Beltzner wrote:
>> On 2010-01-18, at 8:16 AM, Wolfgang Rosenauer wrote:
>>> Firefox still _is_ a MoCo product so the final decision is done there as
>>> I understood.
>>
>> That's true, the trademark rests with the Corporation, but the procedures by which these decisions are made still fall within Mozilla Project governance.
>
> Not wanting to split hairs here, but isn't the trademark with the Foundation actually and Corporation making the product decisions? ;-)

Yes, quite right, I spoke incorrectly. The trademark(s) rest with the Mozilla Foundation, which is the sole director of the Corporation and sets priorities for the community to execute on.

cheers,
mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Wolfgang Rosenauer-2
In reply to this post by Wolfgang Rosenauer-2
Am 18.01.2010 14:29, schrieb Mike Beltzner:
> On 2010-01-18, at 8:16 AM, Wolfgang Rosenauer wrote:
>
>> That sounds much better then. Still it might be too many changes for
>> some Linux vendors.
>
> Do you have specific examples of what you would consider to be too many changes?

Again I can state how it basically works within the openSUSE project
(while the same probably holds true for most of the long term supported
distros).
By policy during the lifetime of a supported Linux distro version there
are no version updates allowed. Only fixes for critical bugs and
security fixes are allowed (basically similar as to what you are doing
nowadays). These are backported to the shipped version.

Firefox already got an extra rule because:
1. you are promising to only do security and stability fixes while
   keeping the API
2. it's sometimes impossible to backport easily w/o taking further
   patches

So a policy change what is allowed in a stable branch would probably
cause a reevaluation from the distributor if he can safely take the
latest version.

>> I can only speak informed for openSUSE and yes, we are doing usually
>> doing every security update within a stable branch with Firefox and
>> xulrunner kept in sync. And afaics that's the same for the other popular
>> distros.
>
> Good to know; there was recently a question about whether or not we needed to do nightly builds for xulrunner - any input there?

hmm, I'm wondering how that would affect the above? Not sure which issue
that would be supposed to solve. Is there public discussion about that
somewhere?

Wolfgang
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Asa Dotzler-2
In reply to this post by Robert Kaiser
On 1/18/2010 5:51 AM, Robert Kaiser wrote:

> Mike Beltzner wrote:
>> On 2010-01-18, at 8:16 AM, Wolfgang Rosenauer wrote:
>>> Firefox still _is_ a MoCo product so the final decision is done there as
>>> I understood.
>>
>> That's true, the trademark rests with the Corporation, but the
>> procedures by which these decisions are made still fall within Mozilla
>> Project governance.
>
> Not wanting to split hairs here, but isn't the trademark with the
> Foundation actually and Corporation making the product decisions? ;-)
>
> At least that's how I understand it - though, of course, discussions are
> much broader, but the decision making needs to be concentrated
> somewhere. Though I could easily be wrong and it's a democratic project
> now. :P


Actually, decision making needs to be distributed, not concentrated. We
have a system for distributed decision making that pre-dates both the
Mozilla Foundation and the Mozilla Corporation by more than half a
decade and is still the system in use today.

That system is the Module Owner system.

- A
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Boris Zbarsky
In reply to this post by Wolfgang Rosenauer-2
On 1/18/10 8:20 AM, Wolfgang Rosenauer wrote:
> Hmm, not quite sure what you mean. There are indeed not really api
> changes within a stable branch. But building stuff against
> xulrunner.next always required changes to downstream users in the past.

Are we we're talking about binary xulrunner consumers, or are we talking
about JS+xul+html-only xulrunner apps?  Or some of both?

And of the binary case, when you say "changes" do you mean "needs a
recompile" or "needs code-level changes"?  I can see both being issues
depending on what's being done with xulrunner....

Ideally we would like to be able to expose somewhat stable API to JS.
The story on binary things is more in flux as I understand, with some
disagreement about what things we should or should not be changing, at
least in major releases.

In minor releases, we've generally aimed at not changing any nsI*
things, but I believe the thinking is that we need to stop doing that
for nsIDocument and nsIContent and nsIFrame and the like.  So we would
be shipping changes to those in security fixes as needed, quite apart
from Lorentz-like things.

Would that cause issues for your downstream users?

-Boris

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Wolfgang Rosenauer-2
Am 18.01.2010 20:36, schrieb Boris Zbarsky:
> On 1/18/10 8:20 AM, Wolfgang Rosenauer wrote:
>> Hmm, not quite sure what you mean. There are indeed not really api
>> changes within a stable branch. But building stuff against
>> xulrunner.next always required changes to downstream users in the past.
>
> Are we we're talking about binary xulrunner consumers, or are we talking
> about JS+xul+html-only xulrunner apps?  Or some of both?

Some of both. More of the former.

> And of the binary case, when you say "changes" do you mean "needs a
> recompile" or "needs code-level changes"?  I can see both being issues
> depending on what's being done with xulrunner....

Recompile is usually not enough. If we are lucky it's about build system
changes only just because the SDK package is changing apparently with
almost every major/minor release.

> Ideally we would like to be able to expose somewhat stable API to JS.
> The story on binary things is more in flux as I understand, with some
> disagreement about what things we should or should not be changing, at
> least in major releases.

The binary things probably will solve by itself since almost everyone is
moving away from embedding Gecko anyway. Quite a lot of that happened
during the last few years.

> In minor releases, we've generally aimed at not changing any nsI*
> things, but I believe the thinking is that we need to stop doing that
> for nsIDocument and nsIContent and nsIFrame and the like.  So we would
> be shipping changes to those in security fixes as needed, quite apart
> from Lorentz-like things.
>
> Would that cause issues for your downstream users?

Hmm, wasn't it nsIDocument which broke Eclipse between 1.9.0 and 1.9.1?
Anyway, I also know that downstream consumers sometimes do the wrong
thing for example with Eclipse which was specifying to work with 1.9.*
maxversion. That's only partly related but at least shows that a simple
installation of an additional xulrunner can and most likely will break
some apps. I don't argue that this happens but I don't want that to
happen within a stable branch.

Wolfgang
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Boris Zbarsky
On 1/18/10 5:08 PM, Wolfgang Rosenauer wrote:
> The binary things probably will solve by itself since almost everyone is
> moving away from embedding Gecko anyway. Quite a lot of that happened
> during the last few years.

Yes, but I'm not convinced that's a good thing. ;)

> Hmm, wasn't it nsIDocument which broke Eclipse between 1.9.0 and 1.9.1?

Quite possible!  I'd love to know what they're using our internal data
structures for, though, and what we can do to make it easier for them
not to.

>  That's only partly related but at least shows that a simple
> installation of an additional xulrunner can and most likely will break
> some apps. I don't argue that this happens but I don't want that to
> happen within a stable branch.

The problem is that we need to be able to make changes even on stable
branches that change internal data structures... and it sounds like
various consumers are depending on them.  That's a bad situation to be
in; is there anything we can do to get out of it?

-Boris

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Gervase Markham
In reply to this post by Robert Kaiser
On 18/01/10 16:02, Mike Beltzner wrote:
> Yes, quite right, I spoke incorrectly. The trademark(s) rest with the
> Mozilla Foundation, which is the sole director of the Corporation and
> sets priorities for the community to execute on.

And, just to make sure the waters are sufficiently muddied ;-), the
Foundation licenses the trademark to the Corporation for its use.

Gerv

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Robert Kaiser
In reply to this post by Asa Dotzler-2
Asa Dotzler wrote:
> Actually, decision making needs to be distributed, not concentrated. We
> have a system for distributed decision making that pre-dates both the
> Mozilla Foundation and the Mozilla Corporation by more than half a
> decade and is still the system in use today.
>
> That system is the Module Owner system.

Right, and that system works very well due to having explicit decision
makers, the module owners, which just happen to be MoCo employees for
almost all matters that specifically concern Firefox. ;-)

And so the circle closes.

In any case, the discussion about this is mostly superfluous, the
important part is the core of the original question about security fixes
vs. features in minor updates, and not what exactly MoCo has to do with
it (I know, I have chimed in with this as well). :)

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Grant Gayed
In reply to this post by Boris Zbarsky
> wasn't it nsIDocument which broke Eclipse between 1.9.0 and 1.9.1?

I think you're thinking of nsIDocShell, which broke several older versions
of eclipse.  Eclipse is now using nsIWebBrowserStream instead, so at least
this part is stabilized.

Between 1.9.1 and 1.9.2 there were actually only two interface changes that
affected eclipse, which was less than usual: nsIScriptGlobalObject and
nsIScriptContext.  Eclipse used to execute javascript simply by setting the
url to javascript://<content>;void(0);, but as of 1.9 this began executing
the javascript asynchronously, so Eclipse changed to call
JS_EvaluateUCScriptForPrincipals(...) instead.  If there's another way to
execute javascript synchrously using frozen api then it would be helpful to
know.

Thanks!
Grant


"Boris Zbarsky" <[hidden email]> wrote in message
news:[hidden email]...

> On 1/18/10 5:08 PM, Wolfgang Rosenauer wrote:
> > The binary things probably will solve by itself since almost everyone is
> > moving away from embedding Gecko anyway. Quite a lot of that happened
> > during the last few years.
>
> Yes, but I'm not convinced that's a good thing. ;)
>
> > Hmm, wasn't it nsIDocument which broke Eclipse between 1.9.0 and 1.9.1?
>
> Quite possible!  I'd love to know what they're using our internal data
> structures for, though, and what we can do to make it easier for them
> not to.
>
> >  That's only partly related but at least shows that a simple
> > installation of an additional xulrunner can and most likely will break
> > some apps. I don't argue that this happens but I don't want that to
> > happen within a stable branch.
>
> The problem is that we need to be able to make changes even on stable
> branches that change internal data structures... and it sounds like
> various consumers are depending on them.  That's a bad situation to be
> in; is there anything we can do to get out of it?
>
> -Boris
>


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Benjamin Smedberg
In reply to this post by Wolfgang Rosenauer-2
On 1/18/10 6:00 AM, Wolfgang Rosenauer wrote:

> Many Linux distributions are currently shipping Firefox as a combination
> of xulrunner and firefox for various reasons. The important thing is
> that on Linux quite some applications use xulrunner (or only its gtk
> embedding widget). With the security and stability patch level updates
> that usually worked quite well. With feature updates I'm expecting API
> breakage and xul incompatibilities to happen commonly.
>
> I wonder what or if MoCo has any idea how that should work?

There are two different issues here:

The proposed plan for Firefox "Lorentz" is to add the OOPP feature to the
platform in a 1.9.2.x update of the platform. This should (fingers crossed)
not involve any API or XUL changes at all: it is almost entirely an additive
change. I would expect Linux distros to take XULRunner 1.9.2.x like any
other minor update. I'd be happy to coordinate additional testing of that
project branch against Linux distros if that would be useful.

At some point, we may decide to do an unprompted (minor) update of Firefox
3.5 -> 3.6. This is still a major version upgrade of xulrunner (1.9.1 ->
1.9.2). As far as I know we have not actually made a decision whether we
plan to do this unprompted update in the future. We have even less made a
decision on how long the platform engineers would would continue to support
the 1.9.1 branch after that update.

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Boris Zbarsky
In reply to this post by Grant Gayed
On 1/19/10 11:18 AM, Grant Gayed wrote:
> I think you're thinking of nsIDocShell, which broke several older versions
> of eclipse.  Eclipse is now using nsIWebBrowserStream instead, so at least
> this part is stabilized.

Ah, and nsIDocShell would probably not be changing in a minor update
anyway; it's too public-facing.  OK, good.

> Between 1.9.1 and 1.9.2 there were actually only two interface changes that
> affected eclipse, which was less than usual: nsIScriptGlobalObject and
> nsIScriptContext.  Eclipse used to execute javascript simply by setting the
> url to javascript://<content>;void(0);, but as of 1.9 this began executing
> the javascript asynchronously, so Eclipse changed to call
> JS_EvaluateUCScriptForPrincipals(...) instead.  If there's another way to
> execute javascript synchrously using frozen api then it would be helpful to
> know.

JS_EvaluateUCScriptForPrincipals (the JSAPI entry point) is effectively
frozen API, modulo the issue of getting a principal.

That said, you can continue using a javascript: URI if you want.  You'd
just have to create the channel yourself, set executeAsync to false, add
it to the right loadgroup, and then open it.  That depends on more
unfrozen stuff than the jsapi call, possibly.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Gervase Markham
In reply to this post by Robert Kaiser
On 19/01/10 15:15, Robert Kaiser wrote:
> Right, and that system works very well due to having explicit decision
> makers, the module owners, which just happen to be MoCo employees for
> almost all matters that specifically concern Firefox. ;-)

Module Ownership is independent of employment, and module owners are
supposed to make the decisions which are best for the Mozilla project.
Given that Firefox is an enormous part of what the Mozilla project does,
a lot of those decisions will be to do what's best for Firefox. But if
you feel that a module owner has made a decision which isn't in the best
interests of the whole project's goals, or has negatively affected
non-Firefox parts of the project unnecessarily, you should let me or
another MoFo person know.

In the mean time, let's not case aspersions on the decision-making
structures without evidence.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Gecko - Firefox - security/feature updates

Robert Kaiser
Gervase Markham wrote:
> On 19/01/10 15:15, Robert Kaiser wrote:
>> Right, and that system works very well due to having explicit decision
>> makers, the module owners, which just happen to be MoCo employees for
>> almost all matters that specifically concern Firefox. ;-)
>
> Module Ownership is independent of employment, and module owners are
> supposed to make the decisions which are best for the Mozilla project.

Sure, that's why I said "happen to be" - and it's surely not wrong that
MoCo tends to employ high-ranking and quite ingenious community members.

> In the mean time, let's not case aspersions on the decision-making
> structures without evidence.

Who did that? I didn't talk about anything being wrong or such, I just
noted an observation. I also didn't accuse anyone to have done something
wrong.

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12