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
Summary:
Currently we have iframe mozbrowser which has a bunch additional
functionality than simple iframe and is a top level browsing context
by itself. Having webview avoids overloading iframe and provides
clarity. We also think this is the right direction towards the
standardization of
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 n...@parkwaycc.co.uk wrote:
Josh Matthews wrote:
As far as I can tell, nsWindowMediator::mListLock protects mOldestWindow
and
On Mon, Oct 13, 2014 at 4:23 AM, Robert O'Callahan rob...@ocallahan.org wrote:
On Sun, Oct 12, 2014 at 12:06 PM, Giuseppe Bilotta
giuseppe.bilo...@gmail.com wrote:
Indeed. My patch only aims at providing a generic fallback. In
contexts where it is known how the desktop environment handles the
On Sun, Oct 12, 2014 at 6:37 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Sun, Oct 12, 2014 at 1:41 AM, Giuseppe Bilotta
giuseppe.bilo...@gmail.com 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
On Fri, Oct 10, 2014 at 4:46 PM, Nicolas Silva nical.si...@gmail.com 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
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 (陳侃如) kc...@mozilla.com wrote:
Summary:
Currently we have iframe mozbrowser which has a
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 iframe
mozbrowser? Probably not an
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 Mon, Oct 13, 2014 at 2:54 AM, Kan-Ru Chen (陳侃如) kc...@mozilla.com
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 webview implementation similar to this
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
On Mon, Oct 13, 2014 at 11:00 AM, Daniel Veditz dved...@mozilla.com 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
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 of
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 Mon, Oct 13, 2014 at 4:36 PM, Kan-Ru Chen (陳侃如) kc...@mozilla.com wrote:
Jonas Sicking jo...@sicking.cc 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,
On Mon, Oct 13, 2014 at 5:37 PM, Chris Hofmann chofm...@mozilla.com 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
On Mon, Oct 13, 2014 at 05:09:41PM -0700, Kyle Huey wrote:
On Mon, Oct 13, 2014 at 4:54 PM, Chris More cm...@mozilla.com 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
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
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, the win32
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 cm...@mozilla.com wrote:
Does anyone know or could any of you create a breakdown of the major blocks
of the Firefox installer and each of their
On Tue, Oct 14, 2014 at 12:06 PM, Joshua Cranmer pidgeo...@gmail.com
wrote:
I nominally agree with this sentiment, but there are a few caveats:
1. nsITreeView and xul:tree exist and are usable in Mozilla code today.
No HTML-based alternative to these are so easily usable.
2. The main
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 Mon, Oct 13, 2014 at 5:52 PM, Gregory Szorc g...@mozilla.com 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
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
Jonas Sicking jo...@sicking.cc writes:
On Mon, Oct 13, 2014 at 4:36 PM, Kan-Ru Chen (陳侃如) kc...@mozilla.com wrote:
Jonas Sicking jo...@sicking.cc writes:
This will only be exposed to privileged and certified apps, right?
Other content that does createElement(webview) will simply get a
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 xul:tree exist and are usable in Mozilla code
today. No HTML-based alternative to these are so easily usable.
There are many lazy-rendering infinite
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.
在
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 xul:tree exist and are usable in Mozilla code
today. No HTML-based alternative to these are so easily usable.
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 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 one)
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
31 matches
Mail list logo
