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*
On 2014-08-27 1:53 AM, Nicholas Nethercote wrote:
On Wed, Aug 27, 2014 at 5:49 AM, Zack Weinberg za...@panix.com wrote:
Seems to me there might be value in applying video controls-style controls
to animated imgs *in general* -- not just for mobile.
That's a great idea!
Looks like that's
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
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
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, restart
-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 that
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
-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 before the user has picked the ultimate
-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 have
-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 create
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
-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 za...@panix.com
wrote:
The downside of turning this on would be that any switch
statements that *deliberately* include only a subset of the
enumerators
-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
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 removing
-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,
-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 za...@panix.com
wrote:
Then, when you get a false-positive maybe-uninitialized warning,
you could just replace T var; with mfbt::ConditionalUseT
-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
through a flood of preexisting
-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, etc. on gcc
-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.
We
-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 now be accepted? Those are the only
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 ishik...@yk.rim.or.jp 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
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
On 2014-01-06 7:58 PM, Karl Tomlinson wrote:
smaug sm...@welho.com 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
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
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 makes
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).
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
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 both
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
On 2013-10-10 12:56 PM, Brian Smith wrote:
On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit
t...@tillschneidereit.net wrote:
On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto gsve...@mozilla.com wrote:
On 10/10/2013 02:36, Zack Weinberg wrote:
In that vein, I think we should take a hard
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
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
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.
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
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
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
targeting it at a document's
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
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,
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 02/25/2013 04:57 PM, Bobby Holley wrote:
On Mon, Feb 25, 2013 at 1:28 PM, Benjamin Smedbergbenja...@smedbergs.uswrote:
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
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_progress
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
Do we have any alternative to math.h when you need pow() or other such
elementary functions? Normally I am Mr. We Should Use The Standard
Library, but math.h in particular tends to have weird shit in it that
causes conflicts with xpcom headers, surprising behavior when everything
isn't a
On 2013-01-16 2:38 PM, Benoit Jacob wrote:
For starters, the standard C++ cmath library is already much better.
I was under the impression that the cwhatever headers could not be
used in Mozilla code. Is that no longer the case?
I also expect that cmath should contain at least as much
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
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-12 1:44 PM, Robert O'Callahan wrote:
On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg za...@panix.com 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 namespace
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
On 2012-11-09 10:49 PM, Robert O'Callahan wrote:
On Fri, Nov 9, 2012 at 10:14 PM, Zack Weinberg za...@panix.com 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
On 2012-10-17 4:07 AM, Henri Sivonen wrote:
On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg za...@panix.com 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
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
53 matches
Mail list logo
