Given that everyone else working in this area agrees that UTF-8 file
paths are the Right Thing and wants to desupport legacy encodings, I
would now vote for suggestion 1 (contra what I said last year in bug
960957, which amounts to a variation on your suggestion 2). However,
I think it might be a
On 2014-10-03 4:37 AM, Jonathan Kew wrote:
it seems we fetch fonts using
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
which doesn't look even remotely sensible.
Agree, but note that there are no official MIME types for most font
formats. (I *think* application/
On 2014-08-27 12:29 PM, Steve Fink wrote:
Maybe it's just me, but I'm having a lot of trouble following this
thread. Can someone spell out exactly what use cases we're talking about
here? Because I've heard several. Enumerating some of them:
1. I touched a file or files. Compile everything withi
On 2014-08-27 1:53 AM, Nicholas Nethercote wrote:
On Wed, Aug 27, 2014 at 5:49 AM, Zack Weinberg wrote:
Seems to me there might be value in applying -style controls
to animated s *in general* -- not just for mobile.
That's a great idea!
Looks like that's https://bugzilla.m
On 2014-08-25 1:04 PM, Jonas Sicking wrote:
That said, if you have ideas for how we can do even better, definitely
speak up. I'd be happy to stop downloading animated gifs over a
certain size over mobile connections if we can have some UI which lets
the user resume the download.
Seems to me th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
'Way back in February I was musing about the possibility of a mfbt
helper template that would allow us to silence "variable X might be
used uninitialized" warnings without the negative effects of
default-initializing those variables (mainly, that tha
On 06/28/2014 08:12 AM, Tobias Besemer wrote:
>
> Forgetting closed pages - or the data to a page - would only be a
> problem is a scenario like this: The user editing a large text in
> a wiki, don't save it, close the page by mistake, close the
> browser without undo the close of the page, resta
On 2014-06-17 11:01 AM, Nathan Froyd wrote:
[bcc dev-tree-management]
In the continuing effort to make our testsuites more reliable, bug
995417 has landed on inbound. This bug enforces the long-standing
policy of no external network connections in the testsuite with code:
external network conne
On 2014-05-30 12:53 PM, Gervase Markham wrote:
On 29/05/14 07:01, Mike Hoye wrote:
It's become clear in the last few months that the overwhelmingly most
frequent users of MITM attacks are state actors with privileged network
positions either obtaining or coercing keys from CAs,
I don't think t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/25/2014 02:08 PM, Zack Weinberg wrote:
> Bug 961080 asks for the new download manager to "support group and
> world-writable umasks for downloaded files". It is stalled on a
> design disagreement between me and the OS.Fil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/26/2014 09:03 PM, Boris Zbarsky wrote:
> On 4/26/14, 11:32 AM, Zack Weinberg wrote:
>> it might be better to just create files in the ultimate target
>> directory if we aren't already.
>
> We create the file befo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/26/2014 12:17 PM, Dave Hylands wrote:
>> The basic user/group/other permissions are always set to the
>> mode argument to open() or mkdir(), and-not the umask.
> The permissions used by open are affected by umask. If you use
> open/creat to cr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/25/2014 06:52 PM, Gavin Sharp wrote:
> It would help a lot with bug-clarity if both the "record umask on
> startup" and "add API to OS.File" changes were split into their
> own bugs. The debate is really about the OS.File API.
Yeah, I should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/25/2014 04:04 PM, Wesley Hardman wrote:
> On 2014-04-25 15:26, Zack Weinberg wrote:
>
> Shouldn't creating a file or directory, simply inherit the
> permissions from the parent? That is what I would expect (at
> le
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/25/2014 03:15 PM, Ralph Giles wrote:
> On 2014-04-25 11:47 AM, Mike Hoye wrote:
>
>> Because people download executable files with the expectation
>> that they can easily execute them.
>
> I ask because allowing web content to add executable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bug 961080 asks for the new download manager to "support group and
world-writable umasks for downloaded files". It is stalled on a design
disagreement between me and the OS.File maintainers (well, it is also
stalled because my development box corrup
On 2014-04-21 1:07 PM, Steve Fink wrote:
On Sat 19 Apr 2014 08:36:22 AM PDT, ISHIKAWA,chiaki wrote:
egrep "^(\\[[0-9]*\\] |)WARNING" $1 | egrep NS_ENSURE | grep -v "sort
operation has occurred for the SQL statement" | sort | uniq -f1 -c |
sort -n -r
It'd be easier if you threw in a *little* b
On 2014-04-07 6:00 AM, Karl Tomlinson wrote:
chiaki ISHIKAWA writes:
I think 7.2 10 is also relevant here.
--- quote ---
An expression of arithmetic or enumeration type can be converted
to an enumeration type explicitly. The
value is unchanged if it is in the range of enumeration values of
the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/02/2014 07:37 AM, Aryeh Gregor wrote:
> On Tue, Apr 1, 2014 at 5:56 PM, Zack Weinberg
> wrote:
>> The downside of turning this on would be that any switch
>> statements that *deliberately* include only a subset of the
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
This is a bit of a tangent, but: There are a whole bunch of places in
layout, and probably elsewhere, where we have the following catch-22:
if you have a switch statement over the values of an enumeration, gcc
and clang (with -Wall) will warn you abo
On 03/02/2014 01:58 PM, Asa Dotzler wrote:
> How much simpler could our style code be if we followed this path?
> What do the standards and other browser vendors say about this?
> Horrible idea? Great idea? Mixed?
>
> "This is in preparation for simplifying the Blink style resolution
> code by rem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/28/2014 06:04 PM, Botond Ballo wrote:
>>> Is there a way to make the template generate 'T var = var;' in
>>> the release case when there's no initializer? That's be a
>>> useful hack to silence -Wunused-variable,
>>> -Wsometimes-uninitialized,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/28/2014 05:19 PM, Ralph Giles wrote:
> On 2014-02-28 1:52 PM, Zack Weinberg wrote:
>
>> Yeah, I guess you would. We could maybe just live with that -
>> at least, what *I* personally care about is not having to wade
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/28/2014 04:24 PM, Nicholas Nethercote wrote:
> On Sat, Mar 1, 2014 at 3:26 AM, Zack Weinberg
> wrote:
>>
>> Then, when you get a false-positive maybe-uninitialized warning,
>> you could just replace T var; with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
This is a half-baked idea that occurred to me in the shower this
morning, but I think it's worth at least looking at. The trouble with
squelching maybe-uninitialized warnings via initialization, when
manual inspection indicates there's no problem, i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/27/2014 03:11 PM, Karl Tomlinson wrote:
> Daniel Holbert writes:
>
>> On 02/27/2014 10:26 AM, Zack Weinberg wrote:
>>> Does that mean a patch to squelch the uninitialized variable
>>> warnings in layout will n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/23/2014 11:54 PM, Daniel Holbert wrote:
> On 02/22/2014 12:26 PM, Hubert Figuière wrote:
>
> FWIW, I (and others) have been working on that, as a side project,
> for a while now, and I think we're actually in pretty good shape
> right now.
>
On 2014-01-29 4:21 PM, Anthony Jones wrote:
I don't think we should attempt style rewriting.
One thing I wanted to explain is why I have focussed on
clang-format-diff more than clang-format. My approach is to stop
introducing ugliness so that we ratchet towards consistency. I suggest
we do the
On 2014-01-17 4:39 AM, Henri Sivonen wrote:
On Thu, Jan 16, 2014 at 7:28 PM, ISHIKAWA,chiaki wrote:
I found that TB generates during its execution
UTF-8 file path name strings WITHOUT BOM and
still contain supposedly a valid UTF8 path name.
I'm pretty sure that file system paths on Linux are
On 2013-11-27 2:36 AM, Gabriele Svelto wrote:
While looking through bugzilla I often stumble in my searches on old
bugs - sometimes very old - which after a quick look I realize have
either already been fixed or won't be (because they pertain to some old,
unsupported platform for example).
Much
On 2013-11-26 5:40 AM, Neil wrote:
Henri Sivonen wrote:
On Windows, do we really need to pay homage to the pre-NT legacy when
doing Save As? How about we just use UTF-8 for "HTML Page, complete"
reserialization like on Mac?
You'll need a BOM, of course.
(MXR turns up so little that it make
On 2014-01-07 6:39 AM, matteosistise...@gmail.com wrote:
On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the
comments I can't see any valid argument that backs up the decision to
not fix the issue. At least none that would stand to the objection
which I posted as a comment:
Having a s
On 2014-01-06 7:58 PM, Karl Tomlinson wrote:
smaug writes:
Why this deprecation?
NS_ENSURE_ macros hid return paths.
That was exactly why they were a Good Thing! Normal control flow was
emphasized.
zw
___
dev-platform mailing list
dev-platfo
Count me as another person in favor of an 80-column hard limit because
of being able to open two files side-by-side with that limit, but not
anything wider (even 100 is too wide). I spend a lot of time with an
editor window tiled against a whole bunch of MXR tabs.
I either don't care or can l
On 2013-11-20 12:37 PM, Benoit Jacob wrote:
Talking about ideas for further extending the impact of UNIFIED_SOURCES, it
seems that the biggest limitation at the moment is that sources can't be
unified between different moz.build's. Because of that, source directories
that consist of many small su
On 2013-11-18 5:41 PM, Ehsan Akhgari wrote:
I wouldn't go all the way to that extreme. The list of broken system
headers is unfortunately quite large, and we already have lots of this
pattern in the tree:
#ifdef MyFunction
// screw you, windows.h/X.h/etc.
#undef MyFunction
#endif
A small not
On 2013-10-25 11:10 AM, Ehsan Akhgari wrote:
On 2013-10-25 10:45 AM, Erik Rose wrote:
... would it be better, from your point of view, to
index the generated files or to magically turn up the IDL line
"attribute short foo" when you search for "function:GetFoo" or
"function:SetFoo"? (I'm not sure
On 2013-10-11 1:08 PM, Ralph Giles wrote:
On 2013-10-10 12:28 PM, Steve Fink wrote:
It seems like the optimal efficiency vs surface exposure vs frequency
of use tradeoff would be to do everything but the top formats (JPG,
PNG, GIF?) in JS.
That's what we do today. We support those three image
On 2013-10-10 12:56 PM, Brian Smith wrote:
On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit
wrote:
On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto wrote:
On 10/10/2013 02:36, Zack Weinberg wrote:
In that vein, I think we should take a hard look at the image decoders.
...
Considering
On 2013-10-09 12:01 PM, Gervase Markham wrote:
In the spirit of learning from this, what's next on the chopping block?
In between "keep the C++ implementation" and "scrap entirely" is
"reimplement in JS", and I think that should be seriously considered for
things like XSLT where there's no qu
On 2013-10-02 12:06 PM, Botond Ballo wrote:
* Digit separators: int x = 1'000'000; // don't ask
Gah. Breaks notion of a pp-number. Why on earth not 1_000_000, which
doesn't?
zw
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 2013-09-23 4:29 PM, Hubert Figuière wrote:
PS: I truly believe that we should drop plugin support all together, but
that's not what I'm discussing here.
I think if we think our options going forward are "implement PPAPI" and
"dump plugins altogether", we should seriously consider both.
Ha
All the discussion of fallback character encodings has reminded me of an
issue I've been meaning to bring up for some time: As a user of the
en-US localization, nowadays the overwhelmingly most common situation
where I see mojibake is when a site puts UTF-8 in its pages without
declaring any en
On 2013-03-18 12:39 PM, L. David Baron wrote:
I'd actually like to see Core higher on the list for the
no-canconfirm case. I think it's common for reasonably
well-informed Web developers (who would have been able to choose a
reasonably correct component within Core, given the list) to file
stand
On 2013-03-04 9:53 AM, Boris Zbarsky wrote:
On 3/4/13 9:10 AM, Zack Weinberg wrote:
So I guess the next question is where does one put a capturing event
handler so that it will see *all* events of the relevant type regardless
of which window it was dispatched to or the contents of that window
On 2013-03-03 10:25 PM, Boris Zbarsky wrote:
On 3/3/13 10:12 PM, Zack Weinberg wrote:
If an event is dispatched from C++ using
nsContentUtils::DispatchTrustedEvent with both the 'bubbles' and
'cancelable' flags set false, what precisely is the difference between
targetin
If an event is dispatched from C++ using
nsContentUtils::DispatchTrustedEvent with both the 'bubbles' and
'cancelable' flags set false, what precisely is the difference between
targeting it at a document's window and targeting it at the document's
window's chrome event handler? In particular,
On 2013-02-25 10:51 PM, Justin Dolske wrote:
Would it be helpful to fix this in two stages? EG, go ahead and land
your backend changes now, but continue to use an app-modal dialog (which
is driven by your new events). The new UI could then be investigated
separately as an independent followup.
On 02/25/2013 04:57 PM, Bobby Holley wrote:
On Mon, Feb 25, 2013 at 1:28 PM, Benjamin Smedbergwrote:
On 2/25/2013 4:14 PM, Zack Weinberg wrote:
The current thinking is that we need *some* indication that a print job
is in progress, because we need to prevent the user from closing the tab
https://bugzilla.mozilla.org/show_bug.cgi?id=650960 seeks to replace the
existing print progress bars with something that isn't app-modal.
Ignore musings in the description and first few comments about getting
rid of them entirely and/or waiting for bug 629500. The current
thinking is that we
On 2013-02-04 9:26 AM, Zack Weinberg wrote:
On 2013-02-04 9:20 AM, rvj wrote:
BTW Is there a pref that suppresses the annoying Preview Progress box ..
or least are you able to move it out of the visible display area ?
There isn't a pref,
I misremembered. Does print.show_print_pro
On 2013-02-04 9:20 AM, rvj wrote:
BTW Is there a pref that suppresses the annoying Preview Progress box ..
or least are you able to move it out of the visible display area ?
There isn't a pref, but that box is going to be replaced with something
more modern and more customizable in bug 650960
On 2013-02-01 8:51 AM, rvj wrote:
I use XUL for developing apps that operate like real devices (intended
for touch screen displays)
I simply need to allow a user to select a printer without conventional
system window popups
Please familiarize yourself with the changes being made in bug 6295
On 2013-01-31 1:07 PM, Ted Mielczarek wrote:
> After consideration, I think we ought to just bite the bullet and
disable PGO. We have no other way to fix this issue. All other work we
can do simply pushes it down the road. As our recent history has shown,
we simply don't have the ability to fix
On 2013-01-30 2:23 PM, Daniel Holbert wrote:
However, be warned that there are patches in bug 629500 to get rid of
nsIPrinterEnumerator entirely (though that bug seems to have stalled a
bit, so I don't know how soon that will happen).
It's blocked on Windows-specific fixes (bug 693230) -- it l
On 2013-01-16 2:38 PM, Benoit Jacob wrote:
For starters, the standard C++ library is already much better.
I was under the impression that the headers could not be
used in Mozilla code. Is that no longer the case?
I also expect that should contain at least as much weird shit as
the corre
Do we have any alternative to when you need pow() or other such
elementary functions? Normally I am Mr. We Should Use The Standard
Library, but in particular tends to have weird shit in it that
causes conflicts with xpcom headers, surprising behavior when everything
isn't a 'double', etc. I
On 2012-11-27 6:21 PM, Gregory Szorc wrote:
On 11/27/12 2:55 PM, Chris Peterson wrote:
On 11/27/12 2:35 PM, Gregory Szorc wrote:
I feel the build system should be as fast as possible by default - no
user action necessary. If you find that -j == # cores isn't providing
the fastest builds possibl
On 2012-11-21 12:06 AM, Robert O'Callahan wrote:
I don't know how to set breakpoints by
name on methods of CSSParserImpl, which is in a toplevel anonymous
namespace. Nor can I cast to a CSSParserImpl* in the expression evaluator.
Note that this is the situation where 'static' cannot be used as
On 2012-11-12 1:44 PM, Robert O'Callahan wrote:
On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg wrote:
The scenario I'm concerned with is when a .cpp file does 'using namespace
A;' and then goes on to define a bunch of its *own* symbols; later someone
adds a symbol to name
On 2012-11-10 12:58 AM, Robert O'Callahan wrote:
What exactly is the benefit here? As far as I know, "using namespace A;
using namespace B;" where both A and B define Foo doesn't actually cause a
compile error unless/until the code actually references "Foo".
The scenario I'm concerned with is
On 2012-11-09 10:49 PM, Robert O'Callahan wrote:
On Fri, Nov 9, 2012 at 10:14 PM, Zack Weinberg wrote:
The style guide should forbid `using namespace` altogether. Use only what
you need.
I really don't think it should. I do not want to see source files full of
difficult-to-ma
On 2012-11-09 1:28 PM, Kyle Huey wrote:
I reviewed a patch today that had:
using namespace mozilla;
using namespace dom;
The style guide should forbid `using namespace` altogether. Use only
what you need.
___
dev-platform mailing list
dev-platfor
On 2012-10-17 2:31 PM, Jonas Sicking wrote:
What would be interesting is if we could enable an autohinter in Firefox
and use that in cases when we are sent a font which doesn't contain hints
(is the performance overhead, if any, acceptable?)
I don't have numbers, but I run my Linux desktop with
On 2012-10-17 11:05 AM, Jonathan Kew wrote:
AFAICS, the latest stable release is currently 2.4.10; do you know when
2.4.11 is expected?
Afraid not; we should probably ask Werner.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://li
On 2012-10-17 4:07 AM, Henri Sivonen wrote:
On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg wrote:
Until quite recently the FreeType autohinter did a very bad job on a
surprising number of popular webfonts - rendering letters in the same word
with inconsistent perceptual x-height, for instance
On 2012-10-16 9:42 AM, Henri Sivonen wrote:
(Aside: In a way, it's rather sad how much engineering effort is put
into compressing TrueType hints, when the reason for sending TrueType
hints over the wire is that Microsoft's font rasterizer's are so
backwards that they still need hints even though
On 2012-10-11 3:12 PM, Anthony Jones wrote:
On 11/10/12 19:33, Mike Hommey wrote:
That being said, PGO on Linux is between 5 and 20% improvement on our
various talos tests. That's with the version of gcc we currently use,
which is 4.5. I'd expect 4.7 to do a better job even, especially if we
add
On 2012-10-08 3:05 PM, Gregory Szorc wrote:
We now have a tool in mozilla-central that has a much better UX for
running tests (mach). It's not perfect yet, but it's getting there
(please write patches!).
The build peers (or at least a few of us) really don't like the make
targets to run tests be
On 2012-09-19 1:01 AM, L. David Baron wrote:
On Wednesday 2012-09-19 00:04 -0400, Ehsan Akhgari wrote:
A while ago (I think more than a couple of years ago now), Vlad
implemented FunctionTimer which is a facility to time how much each
function exactly takes to run. Then, I went ahead and instru
On 2012-07-27 2:18 PM, Justin Dolske wrote:
On 7/27/12 4:01 AM, Mike Hommey wrote:
IIRC, there's not much left to add on gecko's end for extensions to be
able to, and I see no compelling reason why we shouldn't add these
remaining bits. Details should be in one of the bugs about mng or jpeg2k.
71 matches
Mail list logo
