Re: Moratorium on new XUL features

There is a lost of falt in XUL, but still have something good, such as tree and the XBL binding, besides, the window elements is also important, because we need it to implement chromeless window, and titlebar, there is no equivalent in HTML/JS, that's must be considerate when propose the removal

Re: Intent to implement: TV Manager API

Yes, It'll only be available to certified apps. Sean - Original Message - > From: "Robert O'Callahan" > To: "Sean Lin" > Cc: dev-platform@lists.mozilla.org > Sent: Friday, October 17, 2014 11:18:30 AM > Subject: Re: Intent to implement: TV Manager API > Will this be restricted to ce

Re: Intent to implement: TV Manager API

Will this be restricted to certified or privileged apps? 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 o

Intent to implement: TV Manager API

Summary:  The TV Manager API provides a bunch of properties and operations to allow Web apps to acquire the information of TV channels and programs, as well as to manage the native TV modules (i.e., tuners) or the  services. Bug:  https://bugzilla.mozilla.org/show_bug.cgi?id=998872 Link to s

Re: The worst piece of Mozilla code

On 2014-10-16, 8:00 PM, Trevor Saunders wrote: On Fri, Oct 17, 2014 at 09:32:20AM +1100, Nicholas Nethercote wrote: On Thu, Oct 16, 2014 at 11:32 PM, Nicholas Nethercote wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact me

Re: The worst piece of Mozilla code

On Fri, Oct 17, 2014 at 09:32:20AM +1100, Nicholas Nethercote wrote: > On Thu, Oct 16, 2014 at 11:32 PM, Nicholas Nethercote > wrote: > > > > I was wondering what people think is the worst piece of code in the > > entire Mozilla codebase. I'll leave the exact meanings of "worst" and > > "piece of

Re: The worst piece of Mozilla code

On 2014-10-16, 6:33 PM, Nicholas Nethercote wrote: On Fri, Oct 17, 2014 at 8:55 AM, Andreas Gal wrote: I would like to nominate image/src/* and in particular its class hierarchy which completely doesn’t make any sense what so ever. imgRequest, imgIRequest, we got it all. Does this cause co

Re: Compiler version expectations

On 2014-10-16, 6:24 PM, Chris Peterson wrote: On 10/16/14 2:27 PM, Ehsan Akhgari wrote: On 2014-10-16, 5:01 PM, Chris Peterson wrote: On 10/16/14 12:49 PM, Jeff Muizelaar wrote: Are there reasons we can’t drop support for these compilers in the 37-38 time frame? Firefox 38 will become the ne

Re: The worst piece of Mozilla code

I am glad to hear there is so much activity happening there. Kind of makes my point though: that code needed it :) Andreas On Oct 16, 2014, at 8:03 PM, Josh Matthews wrote: > I'm not certain that the image/src/ code is as bad as you make out any more. > bholley certainly is no longer the exp

Re: The worst piece of Mozilla code

I'm not certain that the image/src/ code is as bad as you make out any more. bholley certainly is no longer the expert there; I took over a bunch of his work to clean it up a year or two ago, and Seth is the benevolent dictator now and has done some good cleanup work on it as well. Cheers, Jos

Re: The worst piece of Mozilla code

On Thursday 2014-10-16 19:45 -0300, Andreas Gal wrote: > The code is really bizarre, needlessly complex and impossible to understand > and maintain. We could use a lot of improvements in this area to better > decide what images to load when and how and when to retain or purge them. Seth has been

Re: The worst piece of Mozilla code

The code is really bizarre, needlessly complex and impossible to understand and maintain. We could use a lot of improvements in this area to better decide what images to load when and how and when to retain or purge them. There is a lot of state machinery and multi-threading at work. I wouldn’t

Re: Using __declspec(thread) on Windows

On Fri, Oct 17, 2014 at 10:10:57AM +1300, Robert O'Callahan wrote: > It would be cool to use fast TLS via __declspec(thread) on Windows (and > __thread on gcc/clang). Due to WinXP bustage that only works for variables > in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in > o

Re: Using __declspec(thread) on Windows

On Fri, Oct 17, 2014 at 10:45 AM, David Major wrote: > > in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but > in > > our shipped Windows builds mozglue.dll is statically linked to > firefox.exe > > so we could put __declspec(thread) variables there. > > What does 'statically

Re: The worst piece of Mozilla code

On Fri, Oct 17, 2014 at 8:55 AM, Andreas Gal wrote: > > I would like to nominate image/src/* and in particular its class hierarchy > which completely doesn’t make any sense what so ever. imgRequest, > imgIRequest, we got it all. Does this cause correctness problems, or is it just hard to read a

Re: The worst piece of Mozilla code

On Thu, Oct 16, 2014 at 11:32 PM, Nicholas Nethercote wrote: > > I was wondering what people think is the worst piece of code in the > entire Mozilla codebase. I'll leave the exact meanings of "worst" and > "piece of code" unspecified... Thanks for the replies so far! I deliberately left this que

Re: Compiler version expectations

On 10/16/14 2:27 PM, Ehsan Akhgari wrote: On 2014-10-16, 5:01 PM, Chris Peterson wrote: On 10/16/14 12:49 PM, Jeff Muizelaar wrote: Are there reasons we can’t drop support for these compilers in the 37-38 time frame? Firefox 38 will become the next ESR. I don't know if that means we should dr

Re: The worst piece of Mozilla code

On Thursday 2014-10-16 05:32 -0700, Nicholas Nethercote wrote: > I was wondering what people think is the worst piece of code in the > entire Mozilla codebase. I'll leave the exact meanings of "worst" and > "piece of code" unspecified... I'd probably pick the table and row height computation code

Re: The worst piece of Mozilla code

I would like to nominate image/src/* and in particular its class hierarchy which completely doesn’t make any sense what so ever. imgRequest, imgIRequest, we got it all. Andreas On Oct 16, 2014, at 6:44 PM, Randell Jesup wrote: >> On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote >> wrote:

Re: Using __declspec(thread) on Windows

> in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in > our shipped Windows builds mozglue.dll is statically linked to firefox.exe > so we could put __declspec(thread) variables there. What does 'statically linked' mean in this context? Mozglue.dll is still a DLL, but yes

Re: The worst piece of Mozilla code

>On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote > wrote: > >> I was wondering what people think is the worst piece of code in the >> entire Mozilla codebase. I'll leave the exact meanings of "worst" and >> "piece of code" unspecified... >> > >Probably not the worst, but always deserves a ment

Re: treating B2G device tests as tier 1

On 2014-10-16, 4:20 PM, Boris Zbarsky wrote: On 10/16/14, 4:01 PM, Ehsan Akhgari wrote: Sure. But you're just describing why tests are useful and an absolute necessity. :-) I think what Bobby was asking for is a much stronger ask that is not really attainable. I think what Bobby was actuall

Re: The worst piece of Mozilla code

roc said: > Probably not the worst, but always deserves a mention: > http://dxr.mozilla.org/mozilla-central/source/layout/xul/nsSprocketLayout.cpp#632 That's relatively short. This is 800 lines, complete with several layers of goto: http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/

Re: Compiler version expectations

Can you please ask them to not use variadic templates too? That also seems to require MSVC 2013. On 2014-10-16, 4:33 PM, Jeff Muizelaar wrote: Type aliasing requires 2013, but we can probably keep them from using that for now. I don’t think asking them to support VS2012 will be too much of a

Re: The worst piece of Mozilla code

On 10/16/14 5:32 AM, Nicholas Nethercote wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of "worst" and "piece of code" unspecified... It's gone now, but I always held a special hate for nsIDialogParamBlock. htt

Re: Compiler version expectations

On 2014-10-16, 5:02 PM, Benjamin Smedberg wrote: On 10/16/2014 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll

Re: Compiler version expectations

On 2014-10-16, 5:01 PM, Chris Peterson wrote: On 10/16/14 12:49 PM, Jeff Muizelaar wrote: Are there reasons we can’t drop support for these compilers in the 37-38 time frame? Firefox 38 will become the next ESR. I don't know if that means we should drop old compilers *before* the ESR or after,

RE: Using __declspec(thread) on Windows

> -Original Message- > From: dev-platform [mailto:dev-platform- > bounces+rstrong=mozilla@lists.mozilla.org] On Behalf Of Robert > O'Callahan > Sent: Thursday, October 16, 2014 2:11 PM > To: dev-platform@lists.mozilla.org > Subject: Using __declspec(thread) on Windows > > It would be

Using __declspec(thread) on Windows

It would be cool to use fast TLS via __declspec(thread) on Windows (and __thread on gcc/clang). Due to WinXP bustage that only works for variables in the .EXE or in DLLs statically linked by the .EXE, so not libxul, but in our shipped Windows builds mozglue.dll is statically linked to firefox.exe s

Re: Compiler version expectations

On 10/16/14 12:49 PM, Jeff Muizelaar wrote: Are there reasons we can’t drop support for these compilers in the 37-38 time frame? Firefox 38 will become the next ESR. I don't know if that means we should drop old compilers *before* the ESR or after, but it should probably inform the decision.

Re: Compiler version expectations

On Thu, Oct 16, 2014 at 2:03 PM, Syd Polk wrote: > > On Oct 16, 2014, at 14:49, Jeff Muizelaar wrote: > >> After some discussion some IRC it was clear that our compiler deprecation >> schedule is not very clear. >> >> Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 >>

Re: Compiler version expectations

On Oct 16, 2014, at 14:49, Jeff Muizelaar wrote: > After some discussion some IRC it was clear that our compiler deprecation > schedule is not very clear. > > Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 > for B2G, I expect we’ll be dropping support for building

Re: Compiler version expectations

On 10/16/2014 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 an

Re: Moratorium on new XUL features

On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch wrote: There are also "interesting" height computation issues that I'm pretty sure > HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a > function of the box model, considering it's not an issue with flexbox... > Yeah. XUL layout

Re: Moratorium on new XUL features

On 16/10/2014 06:15, Boris Zbarsky wrote: On 10/16/14, 5:30 AM, Neil wrote: Out of interest, what does it do that complicates layout? You mentioned the box model of course, but what else is there? There's a bunch of listbox-related frame constructor complexity (and for a while it was a quite l

Re: Compiler version expectations

Type aliasing requires 2013, but we can probably keep them from using that for now. I don’t think asking them to support VS2012 will be too much of a burden. -Jeff On Oct 16, 2014, at 4:29 PM, David Major wrote: > I was thinking it would be nice to support VS2010 as long as any of our main >

Re: Compiler version expectations

On 2014-10-16 12:57 PM, Ehsan Akhgari wrote: > GCC is https://bugzilla.mozilla.org/show_bug.cgi?id=1077549. No > specific bug or plans for MSVC2010, but I'd be open to killing support > for it on the next release train. MSVC 2010 means we have to maintain a separate no-AVX2 config for the media p

Re: Compiler version expectations

I was thinking it would be nice to support VS2010 as long as any of our main channels use it -- meaning we could drop it on the first day of 39. But I have no practical justification for that. If it causes a burden on Skia work then it might be reasonable to switch sooner. > This set: http://ch

Re: treating B2G device tests as tier 1

On 10/16/14, 4:01 PM, Ehsan Akhgari wrote: Sure. But you're just describing why tests are useful and an absolute necessity. :-) I think what Bobby was asking for is a much stronger ask that is not really attainable. I think what Bobby was actually asking for is this: If a patch lands and is

Re: treating B2G device tests as tier 1

On Thu, Oct 16, 2014 at 1:01 PM, Ehsan Akhgari wrote: > On 2014-10-16, 3:56 PM, Dale Harvey wrote: >> >> >> >> On 16 October 2014 20:55, Ehsan Akhgari > > wrote: >> >> On 2014-10-16, 1:52 PM, Bobby Holley wrote: >> >> On Thu, Oct 16, 2014 at 7:04 PM, Ehs

Re: Compiler version expectations

On Oct 16, 2014, at 3:57 PM, Ehsan Akhgari wrote: > On 2014-10-16, 3:49 PM, Jeff Muizelaar wrote: >> After some discussion some IRC it was clear that our compiler deprecation >> schedule is not very clear. >> >> Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 >> for

Re: treating B2G device tests as tier 1

On 2014-10-16, 3:56 PM, Dale Harvey wrote: On 16 October 2014 20:55, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: On 2014-10-16, 1:52 PM, Bobby Holley wrote: On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>

Re: Compiler version expectations

On 2014-10-16, 3:49 PM, Jeff Muizelaar wrote: After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 an

Re: treating B2G device tests as tier 1

On 16 October 2014 20:55, Ehsan Akhgari wrote: > On 2014-10-16, 1:52 PM, Bobby Holley wrote: > >> On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari > > wrote: >> >> I don't think it's reasonable to assume that the person doing the >> backout has the time or th

Re: The worst piece of Mozilla code

only code? Long time ago I found a PSD file in the Netscape source. About 1MB with a few layers. m On Thu, Oct 16, 2014 at 4:52 PM, Robert O'Callahan wrote: > On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote > wrote: > >> I was wondering what people think is the worst piece of code in the >>

Re: The worst piece of Mozilla code

On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote wrote: > I was wondering what people think is the worst piece of code in the > entire Mozilla codebase. I'll leave the exact meanings of "worst" and > "piece of code" unspecified... > Probably not the worst, but always deserves a mention: http

Compiler version expectations

After some discussion some IRC it was clear that our compiler deprecation schedule is not very clear. Now that we’re using VS2013 on trunk and will soon not being using GCC 4.4 for B2G, I expect we’ll be dropping support for building with VS2010 and GCC 4.4 in the near term. This is importan

Re: HTMLOverlays (was Re: Moratorium on new XUL features)

On 2014-10-16, 1:44 PM, David Rajchenbach-Teller wrote: On 16/10/14 12:54, Ehsan Akhgari wrote: It can be implemented in JS, right? Indeed. I meant, as a JS library by web developers who feel like it's needed, not by us. :-) FWIW I think that XUL overlays are a terrible way of extending

Re: treating B2G device tests as tier 1

On 2014-10-16, 1:52 PM, Bobby Holley wrote: On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: I don't think it's reasonable to assume that the person doing the backout has the time or the expertise to add a test for the broken functionality. Not

Re: treating B2G device tests as tier 1

On Thu, Oct 16, 2014 at 7:04 PM, Ehsan Akhgari wrote: I don't think it's reasonable to assume that the person doing the backout > has the time or the expertise to add a test for the broken functionality. > Not the sheriff certainly, but I think if the regression is severe enough to warrant this

Font problem in FF34a2 with CSS and fallback

Hi, I analyzed some private pages because of a font problem with FF34a2. It was a problem with the font Verdana. Seems the font was "crashed" in my Win7 64bit. See: http://answers.microsoft.com/en-us/windows/forum/windows_7-desktop/verdana-ttf-font-missing-from-windows-7/33da1d97-8ebd-489c-83c5-c

Re: treating B2G device tests as tier 1

On Thu, Oct 16, 2014 at 10:04 AM, Ehsan Akhgari wrote: > On 2014-10-16, 2:51 AM, Bobby Holley wrote: >> >> This has irked me before too. An obvious compromise would that the >> backout proceeds, but it must include a test that would have failed on >> CI when the patch was landed. This puts the onu

Re: HTMLOverlays (was Re: Moratorium on new XUL features)

On 16/10/14 12:54, Ehsan Akhgari wrote: > It can be implemented in JS, right? Indeed. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.m

Re: treating B2G device tests as tier 1

On 2014-10-16, 2:51 AM, Bobby Holley wrote: This has irked me before too. An obvious compromise would that the backout proceeds, but it must include a test that would have failed on CI when the patch was landed. This puts the onus on the owners of the broken functionality to make sure that this s

Re: HTMLOverlays (was Re: Moratorium on new XUL features)

On 2014-10-16, 7:02 AM, David Rajchenbach-Teller wrote: Which actually looks pretty good to me and should perhaps be (re)discussed. It can be implemented in JS, right? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla

Re: The worst piece of Mozilla code

On Thu 16 Oct 2014 15:24, Joshua Cranmer 🐧 writes: > . C > code masquerading as C++ that use XPCOM classes directly. Manual memory > allocation up the wazoo. Cleans temporary files on error but not > success. Hahaha Creat

Re: The worst piece of Mozilla code

On 10/16/2014 7:32 AM, Nicholas Nethercote wrote: Hi, I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of "worst" and "piece of code" unspecified...

Re: Moratorium on new XUL features

On 10/16/14, 5:30 AM, Neil wrote: Out of interest, what does it do that complicates layout? You mentioned the box model of course, but what else is there? There's a bunch of listbox-related frame constructor complexity (and for a while it was a quite lively source of security bugs, too). But

Re: The worst piece of Mozilla code

On 10/16/2014 03:08 PM, Nicolas B. Pierron wrote:> On 10/16/2014 02:32 PM, Nicholas Nethercote wrote: >> I was wondering what people think is the worst piece of code in the >> entire Mozilla codebase. I'll leave the exact meanings of "worst" and >> "piece of code" unspecified... > > Simple, any f

Re: The worst piece of Mozilla code

On 2014-10-16 8:32 AM, Nicholas Nethercote wrote: Hi, I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of "worst" and "piece of code" unspecified... Currently or ever? I mean, if you find somebody in their office today c

Re: The worst piece of Mozilla code

On 10/16/2014 02:32 PM, Nicholas Nethercote wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of "worst" and "piece of code" unspecified... Simple, any file named configure.in in the code base, because deprecated t

Re: The worst piece of Mozilla code

On Thu 16 Oct 2014 14:32, Nicholas Nethercote writes: > I was wondering what people think is the worst piece of code in the > entire Mozilla codebase. I'll leave the exact meanings of "worst" and > "piece of code" unspecified... The LegacyCompExprTransplanter. https://hg.mozilla.org/integration

The worst piece of Mozilla code

Hi, I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of "worst" and "piece of code" unspecified... Thanks. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https

HTMLOverlays (was Re: Moratorium on new XUL features)

Which actually looks pretty good to me and should perhaps be (re)discussed. I wonder if something like HTMLoverlays (certainly extended with a mechanism to help with unloading) could be made part of the Add-on SDK. Cheers, David On 16/10/14 04:53, Gervase Markham wrote: > Although glazou did p

Re: Moratorium on new XUL features

Boris Zbarsky wrote: The situation is that we have a bunch of unmaintained code that complicates layout. Out of interest, what does it do that complicates layout? You mentioned the box model of course, but what else is there? -- Warning: May contain traces of nuts. _

Re: Moratorium on new XUL features

On 15/10/14 14:24, Boris Zbarsky wrote: > I haven't thought much about #3; it's somewhat in its own little world > and has no web tech equivalent. Although glazou did propose one a decade ago: http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html Gerv _