On Mon, Oct 13, 2014 at 11:10:58PM -0700, David Major wrote:
> VS2013 is now on inbound and all Windows builds are green.
>
> (Win64 builds were actually switched late last week, as they are
> unaffected by trains.)
>
> Please file bugs blocking 914596 if you encounter any VS2013-specific
> issue
VS2013 is now on inbound and all Windows builds are green.
(Win64 builds were actually switched late last week, as they are
unaffected by trains.)
Please file bugs blocking 914596 if you encounter any VS2013-specific
issues.
If you're not sure what version you're running, you can:
* Check the pa
On Monday 2014-10-13 15:17 -0400, Benjamin Smedberg wrote:
> it's not the easiest thing in the world to turn that into an actual
> pushlog link which lists the commits in the regression range.
Just a reminder: I expect many of you know this already, but I
think it's worth repeating: if you're us
On Friday 2014-09-19 17:23 -0700, L. David Baron wrote:
> W3C recently published the following proposed recommendation (the
> stage before W3C's final stage, Recommendation):
>
> http://www.w3.org/TR/html5/
> HTML5
>
> There's a call for review to W3C member companies (of which Mozilla
> is o
On 10/13/14 5:37 PM, Chris Hofmann wrote:
and from last year " Firefox installer size: How big is too big? - 2013"
https://groups.google.com/forum/#!searchin/mozilla.dev.planning/installer$20size/mozilla.dev.planning/hPgUBzweL70/NeOjEf0hsh0J
That thread about installer size was regarding the
On Mon, Oct 13, 2014 at 8:56 PM, Joshua Cranmer 🐧 wrote:
> From another point of view: Mozilla, for over a decade, provided a
> relatively featureful toolkit for building UIs known as XUL. If the argument
> is that we should be using HTML instead of XUL, then wouldn't it make sense
> to provide an
On 10/13/2014 10:10 PM, Andrew Sutherland wrote:
On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote:
I nominally agree with this sentiment, but there are a few caveats:
1. nsITreeView and exist and are usable in Mozilla code
today. No HTML-based alternative to these are so easily usable.
There a
I know there is so much alternative for tree in HTML/JS, but the simplest way
is to improve tree directly when you have already use it.
If the XUL is truly dead, then mozilla community should consider to remove it
totally from the codebase, but not reject to improve it.
在 2014年10月14日星期二UTC+8上午1
On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote:
I nominally agree with this sentiment, but there are a few caveats:
1. nsITreeView and exist and are usable in Mozilla code
today. No HTML-based alternative to these are so easily usable.
There are many lazy-rendering infinite tree/table/infinit
Jonas Sicking writes:
> On Mon, Oct 13, 2014 at 4:36 PM, Kan-Ru Chen (陳侃如) wrote:
>> Jonas Sicking writes:
>>
>>> This will only be exposed to privileged and certified apps, right?
>>> Other content that does createElement("webview") will simply get a
>>> HTMLUnknownElement, right?
>>
>> Correc
On 10/13/14 5:16 PM, Justin Dolske wrote:
On 10/13/14 4:54 PM, Chris More wrote:
Why am I asking this?
The win32 Firefox full installer continues to grow (see attachment)
each release and it has been on an increasing growth since Firefox
29. Like anything on the web, the time it takes to downl
On Mon, Oct 13, 2014 at 5:52 PM, Gregory Szorc wrote:
> On 10/13/14 5:42 PM, Andreas Gal wrote:
>>
>>
>> I looked at lzma2 a while ago for FFOS. I got pretty consistently 30%
>> smaller omni.ja with that. We could add it pretty easily to our
>> decompression code but it has slightly different memo
On 10/13/14 4:54 PM, Chris More wrote:
I am imagining a pie chart of the the current installer and then a
table of the name of each component, their size (KB or MB), and any
additional meta data.
Pie charts are usually not all that useful in this kind of analysis;
but one is attached based
On Tue, Oct 14, 2014 at 12:06 PM, Joshua Cranmer 🐧
wrote:
I nominally agree with this sentiment, but there are a few caveats:
> 1. nsITreeView and exist and are usable in Mozilla code today.
> No HTML-based alternative to these are so easily usable.
> 2. The main rationale for this feature (bug
On Mon, Oct 13, 2014 at 05:37:23PM -0700, Chris Hofmann wrote:
> On 10/13/14 5:09 PM, Kyle Huey wrote:
> >On Mon, Oct 13, 2014 at 4:54 PM, Chris More wrote:
> >>Does anyone know or could any of you create a breakdown of the major blocks
> >>of the Firefox installer and each of their respective si
On Mon, Oct 13, 2014 at 05:39:31PM -0700, Gregory Szorc wrote:
> On 10/13/14 4:54 PM, Chris More wrote:
> >Does anyone know or could any of you create a breakdown of the major blocks
> >of the Firefox installer and each of their respective sizes or percentage of
> >the whole?
> >
> >For example,
On 10/13/14 5:42 PM, Andreas Gal wrote:
I looked at lzma2 a while ago for FFOS. I got pretty consistently 30% smaller
omni.ja with that. We could add it pretty easily to our decompression code but
it has slightly different memory behavior.
This was discussed in the "Including Adobe CMaps" th
On Mon, Oct 13, 2014 at 05:09:41PM -0700, Kyle Huey wrote:
> On Mon, Oct 13, 2014 at 4:54 PM, Chris More wrote:
> > Does anyone know or could any of you create a breakdown of the major blocks
> > of the Firefox installer and each of their respective sizes or percentage
> > of the whole?
> >
> >
On Mon, Oct 13, 2014 at 5:37 PM, Chris Hofmann wrote:
> one thing to add on Kyle's analysis and numbers is to zip all the files back
> up individually, then measure the size of each, since text files are likely
> to have a higher compression rate than binary.
Pretty much everything in there is bi
On Mon, Oct 13, 2014 at 4:36 PM, Kan-Ru Chen (陳侃如) wrote:
> Jonas Sicking writes:
>
>> This will only be exposed to privileged and certified apps, right?
>> Other content that does createElement("webview") will simply get a
>> HTMLUnknownElement, right?
>
> Correct.
Cool, then this sounds great
On 10/13/14 4:54 PM, Chris More wrote:
Does anyone know or could any of you create a breakdown of the major blocks of
the Firefox installer and each of their respective sizes or percentage of the
whole?
For example, the win32 installer for Firefox 32 is 34MB. The Firefox Growth
team [1] like
On 10/13/14 5:09 PM, Kyle Huey wrote:
On Mon, Oct 13, 2014 at 4:54 PM, Chris More wrote:
Does anyone know or could any of you create a breakdown of the major blocks of
the Firefox installer and each of their respective sizes or percentage of the
whole?
For example, the win32 installer for Fi
On 10/13/14 4:54 PM, Chris More wrote:
Why am I asking this?
The win32 Firefox full installer continues to grow (see attachment)
each release and it has been on an increasing growth since Firefox
29. Like anything on the web, the time it takes to download something
(webpage, binary file, etc.)
On Mon, Oct 13, 2014 at 4:54 PM, Chris More wrote:
> Does anyone know or could any of you create a breakdown of the major blocks
> of the Firefox installer and each of their respective sizes or percentage of
> the whole?
>
> For example, the win32 installer for Firefox 32 is 34MB. The Firefox Gr
Does anyone know or could any of you create a breakdown of the major blocks of
the Firefox installer and each of their respective sizes or percentage of the
whole?
For example, the win32 installer for Firefox 32 is 34MB. The Firefox Growth
team [1] like to know of that 34MB, what is the percent
Jonas Sicking writes:
> This will only be exposed to privileged and certified apps, right?
> Other content that does createElement("webview") will simply get a
> HTMLUnknownElement, right?
Correct.
Kanru
___
dev-platform mailing list
dev-platform@list
On 10/13/2014 5:28 PM, Robert O'Callahan wrote:
Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
desire for these features, but I do not think we should take these patches,
nor any other patches adding features to XUL. XUL is a dead-end technology
and investment in XUL
The next MemShrink meeting is brought to you by
HasEnoughTotalSystemMemoryForSkiaGL()
https://bugzilla.mozilla.org/show_bug.cgi?id=1049251
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we m
On Tuesday 2014-10-14 11:28 +1300, Robert O'Callahan wrote:
> Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
> desire for these features, but I do not think we should take these patches,
> nor any other patches adding features to XUL. XUL is a dead-end technology
> and
Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
desire for these features, but I do not think we should take these patches,
nor any other patches adding features to XUL. XUL is a dead-end technology
and investment in XUL provides minimal returns --- this includes effort
On 10/13/2014 6:03 PM, Mike Hommey wrote:
On Mon, Oct 13, 2014 at 03:17:44PM -0400, Benjamin Smedberg wrote:
tl;dr: I have a tool for generating regression-range links from buildids.
http://bsmedberg.github.io/firefox-regression-range-finder/
Often times when we're investigating regressions (c
I have been running a custom instance of WebPagetest
(http://www.webpagetest.org/) which tests page loading performance for
different bandwidths for Firefox builds on 32 bit Windows 7.
Due to lack of interest, I would like to shut the system down. If you
do not want the tool to be shut down, plea
On Mon, Oct 13, 2014 at 03:17:44PM -0400, Benjamin Smedberg wrote:
> tl;dr: I have a tool for generating regression-range links from buildids.
> http://bsmedberg.github.io/firefox-regression-range-finder/
>
> Often times when we're investigating regressions (crashes, etc), we have the
> build ID o
On Mon, Oct 13, 2014 at 11:00 AM, Daniel Veditz wrote:
> On 10/13/2014 9:15 AM, Jonas Sicking wrote:
>> This will only be exposed to privileged and certified apps, right?
>> Other content that does createElement("webview") will simply get a
>> HTMLUnknownElement, right?
>
> What does an unprivileg
tl;dr: I have a tool for generating regression-range links from
buildids. http://bsmedberg.github.io/firefox-regression-range-finder/
Often times when we're investigating regressions (crashes, etc), we have
the build ID of the nightly where the regression started. But it's not
the easiest thin
On Mon, Oct 13, 2014 at 2:54 AM, Kan-Ru Chen (陳侃如)
wrote:
> Link to standard:
> Currently no formal standard. Ben Francis has created a draft which
> largely resembles the current mozbrowser API. Google and Microsoft both
> have their implementation similar to this proposal.
>
> http://benfr
On Sun, Oct 12, 2014 at 10:26 PM, Giuseppe Bilotta <
giuseppe.bilo...@gmail.com> wrote:
> Yes, sorry, I should have clarified that I meant the DPI for the
> scaling. I can prepare a patch for this too. Should I submit it as a
> second patch in addition to the first I submitted to the bugzilla, or
On 10/13/2014 9:15 AM, Jonas Sicking wrote:
> This will only be exposed to privileged and certified apps, right?
> Other content that does createElement("webview") will simply get a
> HTMLUnknownElement, right?
What does an unprivileged app get if it tries to use ? Probably not an HTMLUnknownEleme
This will only be exposed to privileged and certified apps, right?
Other content that does createElement("webview") will simply get a
HTMLUnknownElement, right?
On Mon, Oct 13, 2014 at 2:54 AM, Kan-Ru Chen (陳侃如) wrote:
> Summary:
> Currently we have which has a bunch additional
> functionality
On Fri, Oct 10, 2014 at 4:46 PM, Nicolas Silva wrote:
> In the mean time we should really detect hidpi screens and default to an
> appropriate scale.
> The current scale is a terrible experience on a hidpi screen. I filed bug
> 1081142.
My finding is that the DPI is detected correctly, but the
On Sun, Oct 12, 2014 at 6:37 PM, Robert O'Callahan wrote:
> On Sun, Oct 12, 2014 at 1:41 AM, Giuseppe Bilotta
> wrote:
>>
>> My finding is that the DPI is detected correctly, but the scale is not
>> set according to it. This is exactly what my RFC patch does. I'll push
>> the patch as a proposed
On Mon, Oct 13, 2014 at 4:23 AM, Robert O'Callahan wrote:
> On Sun, Oct 12, 2014 at 12:06 PM, Giuseppe Bilotta
> wrote:
>>
>> Indeed. My patch only aims at providing a generic fallback. In
>> contexts where it is known how the desktop environment handles the DPI
>> settings, that convention shoul
Windows in general shouldn't be touched OMT. Add a
MOZ_RELEASE_ASSERT(NS_IsMainThread()) when it's touched an remove the lock.
On Tue, Oct 7, 2014 at 1:29 AM, Neil wrote:
> Josh Matthews wrote:
>
> As far as I can tell, nsWindowMediator::mListLock protects mOldestWindow
>> and mTopmostWindow. H
Summary:
Currently we have which has a bunch additional
functionality than simple and is a top level browsing context
by itself. Having avoids overloading and provides
clarity. We also think this is the right direction towards the
standardization of the browser-element.
For the story of
ISHIKAWA,chiaki wrote on 10/11/2014 03:22 PM:
Hi,
> But then I realize that the current dialog mechanism may not have
> such an identifier. (Maybe we can use the string or part of the string
> that is shown in the dialog as a key to distinguish different dialogs?
> Of course, change to existing d
45 matches
Mail list logo
