Intent to unship: xml:base attribute

[Xidorn Quan]

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

Summary:
* It has been removed from the spec years ago.
* No other browser supports it.
* We pay performance penalty for it.
* It makes things trickier for stylo to handle URL values.

The tricky thing is that nsParserUtils::ParseFragment currently relies
on xml:base. That is going to be fixed in
https://bugzilla.mozilla.org/show_bug.cgi?id=1313278

Are there any objections?

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

Re: Deprecating XUL in new UI

[R Kent James]

On 1/16/2017 12:43 PM, Dave Townsend wrote:

One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible.


Would you be open to a team of volunteers working on this issue?

I've been pursing an effort in the state of Washington to get teams of 
prisoners who are graduates of a computer education curriculum to 
contribute to open-source projects. I'm looking for a few projects that 
could have pedagogical value, and could be successfully pursued in an 
environment with severe restrictions such as a prison. The best projects 
have a large, well-defined backlog of similar projects that could be 
pursued after a particular skillset and set of tools is acquired. It 
seems to me like XUL to HTML conversion might fit this well.


I might be able to put together a team of around 5 people on this. Are 
you seriously interested in converting existing XUL to HTML such that 
you might have the patience to work with volunteers on this, and would 
accept patches that met your standards? I would serve as a filter so any 
issues that would be presented publicly would not be trivial hand holding.


I might start with a similar project in Thunderbird because I have 
better contacts there and it might be more approachable.


Are there any good examples of XUL to HTML conversions that have been 
done already? If not, would it be possible to get at least one official 
conversion done that could serve as an example of expected practice?


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

Re: Project Stockwell - February 2017 update

[Joel Maher]

I wonder if we could make a single link in orangefactor that would give you
the range of TEST-UNEXPECTED-FAIL messages to help with this.  I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1339937 to track this, Please
do offer suggestions/use cases for that specific bug.

On Tue, Feb 14, 2017 at 5:24 PM, L. David Baron  wrote:

> On Tuesday 2017-02-07 21:33 -0800, Bill McCloskey wrote:
> > I spent about an hour tonight trying to debug a test failure, and I'm
> > writing this email in frustration at how difficult it is. It seems like
> the
> > process has actually gotten a lot worse over the last few years (although
> > it was never good). Here's the situation I ran into:
>
> Another aspect of debugging test failures that has gotten worse
> recently:
>
>  * If you have an intermittent that's actually affecting the tree,
>it's become harder to see the range of TEST-UNEXPECTED-FAIL
>messages that are occurring.  These used to be present in the
>comments that tbplbot made on bugs, but now it requires following
>a link for each log in the orangefactor interface.  (Having this
>range was useful to me today in fixing 1159532, although clicking
>through to 6 logs was sufficient to help understand the problem.)
>
>This also makes it much harder to tell if bugs are being
>mis-classified (e.g., two different problems being starred into
>one bug).
>
> (I thought the point of structured logging was to make it easier to
> get this sort of data.)
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We should drop MathML

[Jonathan Kingston]

Hi Phil,

I'm going to say this isn't a plan I am aware of (the email you responded
to is pretty old and no know progression since then).

Various bugs are still being raised about modern MathML support (stylo is a
new integration of servo's CSS rendering as part of the quantum project -
https://wiki.mozilla.org/Stylo)
  https://bugzilla.mozilla.org/show_bug.cgi?id=1339711

Secondly when working on a pref for the tor patch uplift to Firefox there
wasn't a notion that we should be removing MathML at all:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1173199

This change is just for Tor users who wish to increase their privacy by
removing a library which has known fingerprinting and exploits in the past.

Thanks
Jonathan


On Wed, Feb 15, 2017 at 4:51 PM,  wrote:

> On Sunday, May 5, 2013 at 11:38:39 AM UTC-4, Benoit Jacob wrote:
> > Hi,
> >
> > Summary: MathML is a vestigial remnant of the XML-everything era, and we
> > should drop it.
> >
>
> This is one of the worst ideas I've ever heard floated around Mozilla,
> dating back to the days when releases were numbered M1, M2 and so on.
>  MathML support is basically the ONLY regard in which Firefox has any real
> differentiator between itself and the rest of the browsers out there.
> Choosing to support MathML is one of the few examples of the Mozilla
> leadership group displaying any real vision and choosing to lead, rather
> than follow, in the browser market.  If you drop MathML support, I say you
> might as well just cancel the Firefox project altogether.
>
>
> Phil
> ___
> 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: We should drop MathML

[motley . crue . fan]

On Sunday, May 5, 2013 at 11:38:39 AM UTC-4, Benoit Jacob wrote:
> Hi,
> 
> Summary: MathML is a vestigial remnant of the XML-everything era, and we
> should drop it.
> 

This is one of the worst ideas I've ever heard floated around Mozilla, dating 
back to the days when releases were numbered M1, M2 and so on.   MathML support 
is basically the ONLY regard in which Firefox has any real differentiator 
between itself and the rest of the browsers out there.  Choosing to support 
MathML is one of the few examples of the Mozilla leadership group displaying 
any real vision and choosing to lead, rather than follow, in the browser 
market.  If you drop MathML support, I say you might as well just cancel the 
Firefox project altogether.  


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