On closing old bugs

[Gabriele Svelto]

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).


I'm always tempted to close the former as duplicates of the actual fix 
and the latter as WONTFIX so that they won't show up on the following 
searches but I'm also afraid that closing a bug several years old is 
akin to thread necromancy [1].


What's the general feeling about this? The relevant MDN page [2] 
mentions that WONTFIX should only be used by module owners and peers so 
that also makes me wary of using it even though in some cases I'm pretty 
sure a bug won't ever be fixed. The typical case being bugs affecting 
dead/unsupported platforms.


 Gabriele

[1] http://en.wiktionary.org/wiki/thread_necromancy
[2] 
https://developer.mozilla.org/en-US/docs/What_to_do_and_what_not_to_do_in_Bugzilla

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [b2g] PSA: Shutting down my mozilla git mirror in three weeks

[Mike Hommey]

On Wed, Nov 27, 2013 at 06:02:42AM +0100, Julien Wajsberg wrote:
> Note, for git lovers, the git remote hg helper seems to work quite well.
> see http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/
> 
> As an occasional gecko developer I'm giving it a try right now and see
> how it goes :)

Note that since then, git remote-hg has made it to the official git
repository, in contrib/remote-helpers.

https://github.com/git/git/blob/master/contrib/remote-helpers/git-remote-hg

It still has the drawback that it uses a local mercurial clone under the
hood, so a git/hg clone takes between 2 and 3 times as much space as it
should.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [b2g] PSA: Shutting down my mozilla git mirror in three weeks

[Julien Wajsberg]

Note, for git lovers, the git remote hg helper seems to work quite well.
see http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/

As an occasional gecko developer I'm giving it a try right now and see
how it goes :)

Le 26/11/2013 20:13, Juan Gómez a écrit :
> Well, I have a fork of mozilla/mozilla-central and it is not disabled. I
> can push commits, browse it via web or clone it.
> Anyway, What do you suggest? moving to git.mozilla.org instead of
> github/gecko-dev?
>
>
>
> On Tue, Nov 26, 2013 at 2:05 AM, Gregory Szorc  wrote:
>
>> It looks like GitHub decided to disable Ehsan's repo and all forks without
>> notice. https://bugzilla.mozilla.org/show_bug.cgi?id=943132 tracks it
>> from our end.
>>
>>
>> On 11/25/13, 11:39 PM, Ehsan Akhgari wrote:
>>
>>> Dear all,
>>>
>>> For the past two and a half years I have been maintaining a git mirror
>>> of mozilla-central plus a lot of the other branches that people found
>>> useful at https://github.com/mozilla/mozilla-central.  Over the years
>>> this proved to be too much work for me to keep up with, and given the
>>> existence of the new git mirrors that are supported by RelEng, I'm
>>> planning to shut down the update jobs for this repository on Friday, Dec
>>> 13, 2013 and take the repository down.
>>>
>>> I strongly suggest that if you have been using and relying on this
>>> repository before, please consider switching to the RelEng repositories
>>> as soon as possible. https://github.com/mozilla/gecko-dev is the main
>>> repository where you can find branches such as trunk/aurora/b2g
>>> branches/etc and https://github.com/mozilla/gecko-projects is a
>>> repository which contains project branches and twigs.  (Note that my
>>> repository hosts all of these branches in a single location, but from
>>> now on if you use both of these branch subsets you will need to have two
>>> upstream remotes added in your local git clone.)
>>>
>>> The RelEng repositories have a similar history line including the CVS
>>> history but they have completely different commit SHA1s, so pulling that
>>> repo into your existing clones is probably not what you want.  If you
>>> don't have a lot of non-merged branches, your safest bet is cloning from
>>> scratch and then port your existing branches manually.  If you have a
>>> lot of local branches, you may want to wait for the script that John
>>> Schoenick is working on in bug 929338 which will assist you in rebasing
>>> those branches on top of the new history line.
>>>
>>> Last but not least, I really hate to have to disrupt your workflow like
>>> this.  I do hope that three weeks is enough advance notice for everybody
>>> to successfully switch over to the new mirrors, but if you have a reason
>>> for me to delay this please let me know and I will do my best to
>>> accommodate.
>>>
>>> Cheers,
>>> --
>>> Ehsan
>>> 
>>>
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-b2g mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HWA and OMTC on Linux

[Benoit Jacob]

Congrats Nick, after all is said and done, this is a very nice milestone to
cross!


2013/11/26 Nicholas Cameron 

> This has finally happened. If it sticks, then after this commit (
> https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=aa0066b3865c) there
> will be no more main thread OpenGL compositing on any platform. See my blog
> post (
> http://featherweightmusings.blogspot.co.nz/2013/11/no-more-main-thread-opengl-in-firefox.html)
> for details (basically what I proposed at the beginning of this thread).
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HWA and OMTC on Linux

[Nicholas Cameron]

This has finally happened. If it sticks, then after this commit 
(https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=aa0066b3865c) there will be 
no more main thread OpenGL compositing on any platform. See my blog post 
(http://featherweightmusings.blogspot.co.nz/2013/11/no-more-main-thread-opengl-in-firefox.html)
 for details (basically what I proposed at the beginning of this thread).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Keywords for flagging unreduced regression windows

[Mats Palmgren]

On 11/26/2013 08:10 PM, Josh Matthews wrote:

* regressionwindow-wanted, testcase-wanted: regression from earlier
versions is present, and some help crafting a testcase/clear steps to
consistently reproduce is desired


I think we should keep "testcase" and "steps to reproduce" as separate
notions.  There is a keyword to flag the absense of the latter:
steps-wanted.


* regressionwindow-wanted, testcase: regression from earlier versions is
present, and good STR have been identified


I don't think we should change "testcase" to also mean "good STR have
been identified".  Again, we have a keyword for the latter: reproducible.
(testcase implies reproducible of course)

As I see it, a testcase is different from good STR.  It's usually
a small standalone file attached on the bug that reproduces the
problem.

So I think we already have keywords to represent the states you want.

* regressionwindow-wanted: regression from earlier versions is present,
but there are not clear, reproducible steps to follow (likely quite
complex/intermittent)

* regressionwindow-wanted, steps-wanted: regression from earlier versions
is present, and some help crafting a testcase/clear steps to consistently
reproduce is desired

* regressionwindow-wanted, reproducible: regression from earlier versions
is present, and good STR have been identified

* regressionwindow-wanted, reproducible, testcase-wanted: as above, but
we still want help producing a testcase from the STR

* regressionwindow-wanted, testcase: regression from earlier versions is
present, and we have a testcase that reproduces the problem

where the last three are variations of the state you labeled as
"good STR have been identified".



so I propose being more explicit about this.


Yes, I fully agree. And that goes for any bug, not just regressions.


Cheers,
Mats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[completed] Re: Disabling today the 10.7 test infrastructure across the board

[Armen Zambrano G.]

This has been completed.
All 10.7 jobs have been disabled.
Those 10.7 machines will be re-purposed as 10.6 machines.
We should have them all re-imaged and operational by next week.

If you find any issues please use
https://bugzilla.mozilla.org/show_bug.cgi?id=942299

cheers,
Armen

On 11/26/2013, 10:11 AM, Armen Zambrano G. wrote:
> This is part 1 of the thread "Proposed changes to RelEng's OSX build and
> test infrastructure".
> 
> I wanted to make it very clear so no one is surprised when it happens.
> 
> cheers,
> Armen
> 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Keywords for flagging unreduced regression windows

[Josh Matthews]

In an attempt to get more people involved with finding regression 
ranges, I'm proposing some standard keywords for relevant bugs:


* regressionwindow-wanted: regression from earlier versions is present, 
but there are not clear, reproducible steps to follow (likely quite 
complex/intermittent)
* regressionwindow-wanted, testcase-wanted: regression from earlier 
versions is present, and some help crafting a testcase/clear steps to 
consistently reproduce is desired
* regressionwindow-wanted, testcase: regression from earlier versions is 
present, and good STR have been identified


The reason behind this proposal is that our mozregression tool recently 
gained the ability to use archived inbound builds, so the output can be 
much more precise now. If a regression has clear steps to reproduce, 
this should be something we can point enthusiastic contributors towards, 
therefore parallelizing our work better. Our current pool of 
regressionwindow-wanted bugs does not satisfy this property, however, so 
I propose being more explicit about this.


Cheers,
Josh
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Shutting down my mozilla git mirror in three weeks

[Ehsan Akhgari]

On 11/26/2013, 2:13 PM, Juan Gómez wrote:

Well, I have a fork of mozilla/mozilla-central and it is not disabled. I
can push commits, browse it via web or clone it.
Anyway, What do you suggest? moving to git.mozilla.org
 instead of github/gecko-dev?


That problem was resolved around 2 hours ago or so.

Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Shutting down my mozilla git mirror in three weeks

[Juan Gómez]

Well, I have a fork of mozilla/mozilla-central and it is not disabled. I
can push commits, browse it via web or clone it.
Anyway, What do you suggest? moving to git.mozilla.org instead of
github/gecko-dev?



On Tue, Nov 26, 2013 at 2:05 AM, Gregory Szorc  wrote:

> It looks like GitHub decided to disable Ehsan's repo and all forks without
> notice. https://bugzilla.mozilla.org/show_bug.cgi?id=943132 tracks it
> from our end.
>
>
> On 11/25/13, 11:39 PM, Ehsan Akhgari wrote:
>
>> Dear all,
>>
>> For the past two and a half years I have been maintaining a git mirror
>> of mozilla-central plus a lot of the other branches that people found
>> useful at https://github.com/mozilla/mozilla-central.  Over the years
>> this proved to be too much work for me to keep up with, and given the
>> existence of the new git mirrors that are supported by RelEng, I'm
>> planning to shut down the update jobs for this repository on Friday, Dec
>> 13, 2013 and take the repository down.
>>
>> I strongly suggest that if you have been using and relying on this
>> repository before, please consider switching to the RelEng repositories
>> as soon as possible. https://github.com/mozilla/gecko-dev is the main
>> repository where you can find branches such as trunk/aurora/b2g
>> branches/etc and https://github.com/mozilla/gecko-projects is a
>> repository which contains project branches and twigs.  (Note that my
>> repository hosts all of these branches in a single location, but from
>> now on if you use both of these branch subsets you will need to have two
>> upstream remotes added in your local git clone.)
>>
>> The RelEng repositories have a similar history line including the CVS
>> history but they have completely different commit SHA1s, so pulling that
>> repo into your existing clones is probably not what you want.  If you
>> don't have a lot of non-merged branches, your safest bet is cloning from
>> scratch and then port your existing branches manually.  If you have a
>> lot of local branches, you may want to wait for the script that John
>> Schoenick is working on in bug 929338 which will assist you in rebasing
>> those branches on top of the new history line.
>>
>> Last but not least, I really hate to have to disrupt your workflow like
>> this.  I do hope that three weeks is enough advance notice for everybody
>> to successfully switch over to the new mirrors, but if you have a reason
>> for me to delay this please let me know and I will do my best to
>> accommodate.
>>
>> Cheers,
>> --
>> Ehsan
>> 
>>
>>
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Shutting down my mozilla git mirror in three weeks

[Ehsan Akhgari]

FWIW the repository is back up now!

On 11/25/2013, 4:46 PM, Aki Sasaki wrote:

Github has closed access to https://github.com/mozilla/mozilla-central :

 This repository has been disabled.
 Access to this repository has been disabled by GitHub staff.
 Contact support to restore access to this repository.

We're currently trying to reach github support to reverse this decision;
it would be much better to do a scheduled rollout than have to scramble
like this.

In the meantime, if you rely on git-based mozilla-central and can move
to gecko-dev sooner, please do so.  gecko-dev is also on
git.mozilla.org, so should the same thing happen there, we have more
options.

If you require support to switch, let's take over #git and see if we can
figure this out together.

On 11/25/13 7:39 AM, Ehsan Akhgari wrote:

Dear all,

For the past two and a half years I have been maintaining a git mirror of
mozilla-central plus a lot of the other branches that people found useful
at https://github.com/mozilla/mozilla-central.  Over the years this proved
to be too much work for me to keep up with, and given the existence of the
new git mirrors that are supported by RelEng, I'm planning to shut down the
update jobs for this repository on Friday, Dec 13, 2013 and take the
repository down.

I strongly suggest that if you have been using and relying on this
repository before, please consider switching to the RelEng repositories as
soon as possible.  https://github.com/mozilla/gecko-dev is the main
repository where you can find branches such as trunk/aurora/b2g
branches/etc and https://github.com/mozilla/gecko-projects is a repository
which contains project branches and twigs.  (Note that my repository hosts
all of these branches in a single location, but from now on if you use both
of these branch subsets you will need to have two upstream remotes added in
your local git clone.)

The RelEng repositories have a similar history line including the CVS
history but they have completely different commit SHA1s, so pulling that
repo into your existing clones is probably not what you want.  If you don't
have a lot of non-merged branches, your safest bet is cloning from scratch
and then port your existing branches manually.  If you have a lot of local
branches, you may want to wait for the script that John Schoenick is
working on in bug 929338 which will assist you in rebasing those branches
on top of the new history line.

Last but not least, I really hate to have to disrupt your workflow like
this.  I do hope that three weeks is enough advance notice for everybody to
successfully switch over to the new mirrors, but if you have a reason for
me to delay this please let me know and I will do my best to accommodate.

Cheers,
--
Ehsan






___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Support for non-UTF-8 platform charset

[Simon Montagu]

On 11/25/2013 01:46 PM, Henri Sivonen wrote:

> Questions:
>
>  * 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?

Do you mean Save As Text? Do we really use the platform charset when
saving as HTML Page, complete? For Save As Text I would have thought
that the time was ripe by now to go over to using UTF-8.

>  * Do we (or gtk) really still support non-UTF-8 platform charset
> values on *nix? (MXR turns up so little that it makes me wonder
> non-UTF-8 support might have already gone away for practical
> purposes.)

You wonder correctly. There are probably vestigial remnants of support
for other platform charsets still around, but I can testify that any
code that I contributed in the last 5 years or more only supports UTF-8
on *nix.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Shutting down my mozilla git mirror in three weeks

[Aki Sasaki]

Github has closed access to https://github.com/mozilla/mozilla-central :

This repository has been disabled.
Access to this repository has been disabled by GitHub staff.
Contact support to restore access to this repository.

We're currently trying to reach github support to reverse this decision;
it would be much better to do a scheduled rollout than have to scramble
like this.

In the meantime, if you rely on git-based mozilla-central and can move
to gecko-dev sooner, please do so.  gecko-dev is also on
git.mozilla.org, so should the same thing happen there, we have more
options.

If you require support to switch, let's take over #git and see if we can
figure this out together.

On 11/25/13 7:39 AM, Ehsan Akhgari wrote:
> Dear all,
> 
> For the past two and a half years I have been maintaining a git mirror of
> mozilla-central plus a lot of the other branches that people found useful
> at https://github.com/mozilla/mozilla-central.  Over the years this proved
> to be too much work for me to keep up with, and given the existence of the
> new git mirrors that are supported by RelEng, I'm planning to shut down the
> update jobs for this repository on Friday, Dec 13, 2013 and take the
> repository down.
> 
> I strongly suggest that if you have been using and relying on this
> repository before, please consider switching to the RelEng repositories as
> soon as possible.  https://github.com/mozilla/gecko-dev is the main
> repository where you can find branches such as trunk/aurora/b2g
> branches/etc and https://github.com/mozilla/gecko-projects is a repository
> which contains project branches and twigs.  (Note that my repository hosts
> all of these branches in a single location, but from now on if you use both
> of these branch subsets you will need to have two upstream remotes added in
> your local git clone.)
> 
> The RelEng repositories have a similar history line including the CVS
> history but they have completely different commit SHA1s, so pulling that
> repo into your existing clones is probably not what you want.  If you don't
> have a lot of non-merged branches, your safest bet is cloning from scratch
> and then port your existing branches manually.  If you have a lot of local
> branches, you may want to wait for the script that John Schoenick is
> working on in bug 929338 which will assist you in rebasing those branches
> on top of the new history line.
> 
> Last but not least, I really hate to have to disrupt your workflow like
> this.  I do hope that three weeks is enough advance notice for everybody to
> successfully switch over to the new mirrors, but if you have a reason for
> me to delay this please let me know and I will do my best to accommodate.
> 
> Cheers,
> --
> Ehsan
> 
> 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [b2g] PSA: Shutting down my mozilla git mirror in three weeks

[Aki Sasaki]

On 11/25/13 2:59 PM, Nicholas Nethercote wrote:
> On Mon, Nov 25, 2013 at 1:46 PM, Aki Sasaki  wrote:
>> Github has closed access to https://github.com/mozilla/mozilla-central :
>>
>> This repository has been disabled.
>> Access to this repository has been disabled by GitHub staff.
>> Contact support to restore access to this repository.
>>
>> We're currently trying to reach github support to reverse this decision;
>> it would be much better to do a scheduled rollout than have to scramble
>> like this.
> Are there plans to move Gaia from Github onto Mozilla servers?  Having
> portions of our primary products on third-party servers is a terrible
> idea.

We have read-only mirrors of gaia on both hg.m.o and git.m.o.
Making Mozilla-hosted repos our repositories-of-record is a larger
discussion; that may get added momentum due to issues like this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MozillaBuild 1.9.0 test build up

[Ryan VanderMeulen]

On 11/26/2013 11:04 AM, Ryan VanderMeulen wrote:

I just uploaded a test build of MozillaBuild 1.9.0. Please try it out
and provide feedback, especially with mozmake.

http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup1.9.0pre.exe

Notable changes in this build:
* Better support for newer MSVC and Windows SDK versions
* Updated Mercurial to version 2.8.0
* Added mozmake (GNU make 4.0 + custom patches)

Please mark any mozmake bugs you come across as blocking bug 927213 and
CC :glandium.

Thanks!

-Ryan


I should also point out that the necessary patches have already landed 
on m-c so that mach will automatically use mozmake over pymake if 
available. So mozmake should "just work" if you use |mach build|.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MozillaBuild 1.9.0 test build up

[Ryan VanderMeulen]

I just uploaded a test build of MozillaBuild 1.9.0. Please try it out 
and provide feedback, especially with mozmake.


http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup1.9.0pre.exe

Notable changes in this build:
* Better support for newer MSVC and Windows SDK versions
* Updated Mercurial to version 2.8.0
* Added mozmake (GNU make 4.0 + custom patches)

Please mark any mozmake bugs you come across as blocking bug 927213 and 
CC :glandium.


Thanks!

-Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Disabling today the 10.7 test infrastructure across the board

[Armen Zambrano G.]

This is part 1 of the thread "Proposed changes to RelEng's OSX build and
test infrastructure".

I wanted to make it very clear so no one is surprised when it happens.

cheers,
Armen


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Support for non-UTF-8 platform charset

[Ted Mielczarek]

On 11/26/2013 6:37 AM, Henri Sivonen wrote:
> On Mon, Nov 25, 2013 at 6:03 PM, Yuri Dario  wrote:
>> the OS/2 port is alive, we already have a beta release for 17.x and a
>> more current version will follow.
> Does this work all happen in forked repositories, such as
> https://github.com/bitwiseworks/mozilla-os2/ ,  or does code still get
> upstreamed to mozilla-central?
>
We have been steadily removing OS/2 support from mozilla-central, so if
the port is still alive it's happening elsewhere. I wouldn't expend any
effort on making anything work for OS/2.

-Ted

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reacting more strongly to low-memory situations in Firefox 25

[Benjamin Smedberg]

On 11/25/13 8:15 PM, Bas Schouten wrote:
I'm a little confused, when I force OOM my firefox build on 64-bit 
windows it -definitely- goes down before it reaches more than 3GB of 
working set. Am I missing something here? 
I think so. I did not mention working set at all. I am merely 
calculating whether users are running win64 or win32, based on whether 
they have 4G of total VM size (win64) or 2G/3G (win32).



I should highlight something here, caching the last N textures is only 
occurring in drivers which do -not- map into your address space as far as I 
have see in my testing. Intel stock drivers seem to map into your address 
space, but do -not- seem to do any caching. The most likely cause of the OOM 
here is simply that currently, we keep both the texture, and a RAM copy around 
of any image in our image cache that has been drawn. This means for users using 
Direct2D with these drivers an image will use twice as much address space as 
for users using software rendering. We should probably alter imagelib to 
discard the RAM copy when having hardware acceleration, and in that case actual 
address space usage should be the same for users with, and without hardware 
acceleration.
Given that the recent Firefox 25 regression occurs for users whether 
acceleration is enabled or disabled, I don't think that acceleration is 
the thing we should be focusing on short-term. But yes, we should 
continue to measure and correct for VM usage as well as total memory 
usage in the graphics space.


I also suspect that we're not dealing with normal memory usage: it seems 
clear that we're leaking someting, because the users who are helping 
figure this out can clearly see issues by loading just a few youtube 
pages in HTML5 video mode and then refreshing them a few times.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Support for non-UTF-8 platform charset

[Henri Sivonen]

On Mon, Nov 25, 2013 at 7:47 PM, Simon Montagu  wrote:

(Replying to @smontagu.org, instead of netscape.com just in case.)

> Do you mean Save As Text? Do we really use the platform charset when
> saving as HTML Page, complete? For Save As Text I would have thought
> that the time was ripe by now to go over to using UTF-8.

Yes, but now I can't locate the code that I thought I was reading, so
let's ignore this aspect.

>>  * Do we (or gtk) really still support non-UTF-8 platform charset
>> values on *nix? (MXR turns up so little that it makes me wonder
>> non-UTF-8 support might have already gone away for practical
>> purposes.)
>
> You wonder correctly. There are probably vestigial remnants of support
> for other platform charsets still around, but I can testify that any
> code that I contributed in the last 5 years or more only supports UTF-8
> on *nix.

OK. Thanks.

On Mon, Nov 25, 2013 at 6:03 PM, Yuri Dario  wrote:
> the OS/2 port is alive, we already have a beta release for 17.x and a
> more current version will follow.

Does this work all happen in forked repositories, such as
https://github.com/bitwiseworks/mozilla-os2/ ,  or does code still get
upstreamed to mozilla-central?

On Mon, Nov 25, 2013 at 11:38 PM, Karl Tomlinson  wrote:
> Does Unicode provide a way to represent broken UTF-8 sequences?

It does not.

On Mon, Nov 25, 2013 at 2:03 PM, Robert O'Callahan  wrote:
> We shouldn't keep anything around just for OS/2 or non-UTF8 *nix, IMHO.

I suggest we get of nsIPlatformCharset as a Gecko-level concept and
let the OS/2 port deal with non-Unicode platform encodings on the
platform-specific widget perimeter. If this means OS/2 needs some
non-Encoding Standard encoders/decoders, I think the OS/2 port should
maintain additional encoders/decoders as part of the OS/2 widget code
(if suitable code isn't available via system APIs on OS/2).

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=943272 and a
bunch of dependencies.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
http://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendations: Performance Timeline, User Timing, JSON-LD

[Till Schneidereit]

I don't know how well (or if at all) the current push for performance
devtools is coordinated with these proposals, but it would certainly be
worth looking into that.

CCing Axel Kratel.


On Tue, Nov 26, 2013 at 12:31 AM, Boris Zbarsky  wrote:

> On 11/25/13 7:07 PM, L. David Baron wrote:
>
>>http://www.w3.org/TR/performance-timeline/
>>Performance Timeline
>>
>>http://www.w3.org/TR/user-timing/
>>User Timing
>>
>
> Have we had anyone at all review these specs?  My past experience with
> that working group and set of editors doesn't make me sanguine about them
> producing specs that can actually be implemented without
> reverse-engineering IE or Chrome
>
> If we _haven't_ had someone look at these before, we should do that now.
>  And we probably need someone whose job description includes
> sanity-checking the stuff this working group produces.
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Support for non-UTF-8 platform charset

[Neil]

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 me wonder non-UTF-8 support might have 
already gone away for practical purposes.)

Gecko gets a little confused when you run Linux on a non-UTF8 file 
system, so I'd agree with this.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there any reason not to shut down bonsai?

[Gervase Markham]

On 21/11/13 21:12, Laura Thomson wrote:
> bonsai is old code, and written in very old-fashioned perl. As such,
> security bugs are frequently filed against it, and it's very hard to
> find people who are willing and able to fix them. If you are willing
> and able, let me know: I can hook you up with bugs as they arise.

We do have Perl expertise in the Bugzilla team...



Seriously: can we put it behind a Mozillians-powered Persona login to
reduce the attack surface somewhat? At least then it would be safe from
automated scans.

Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Analyze C++/compiler usage and code stats easily

[Neil]

Gregory Szorc wrote:


The best way to fetch it is to pull the bookmark tracking it:

  $ hg pull -B gps/build/measure-compiler 
http://hg.gregoryszorc.com/gecko-collab


Or, look for that bookmark at 
http://hg.gregoryszorc.com/gecko-collab/bookmarks and track down the 
changeset.


Note that for bookmarks that don't contain /s you can just use (e.g.) 
http://hg.gregoryszorc.com/gecko-collab/rev/fx to view the changeset.


(Also, while looking at the Mercurial source code to see if I could 
expose hidden changesets through the web UI, I noticed that the 
official resource/URL for linking to changesets is "changeset" not 
"rev." So, all our Bugzilla URLs using /rev/ are using an alias. 
I'm curious if this is intentional or an accident.)


Interestingly the bookmarks page itself links to /rev/ too...

--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unified builds

[Neil]

Ehsan Akhgari wrote:

It's hard to say exactly what's going on here without knowing more 
about how this build is produced.


These are intermittent failures on TBPL, mostly starred by philor.

It would be really great if you could file a bug about this with more 
details on how to reproduce this broken build.


It would be really great if you had followed his link to bug 931642 in 
the first place.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reacting more strongly to low-memory situations in Firefox 25

[Nicholas Nethercote]

On Tue, Nov 26, 2013 at 4:02 AM, Benjamin Smedberg
 wrote:
> In crashkill we have been tracking crashes that occur in low-memory
> situations for a while. However, we are seeing a troubling uptick of issues
> in Firefox 23 and then 25. I believe that some people may not be able to use
> Firefox because of these bugs, and I think that we should be reacting more
> strongly to diagnose and solve these issues and get any fixes that already
> exist sent up the trains.
>
> Followup to dev-platform, please.
>
> = Data and Background =
>
> See, as some anecdotal evidence:
>
> Bug 930797 is a user who just upgraded to Firefox 25 and is seeing these a
> lot.
> Bug 937290 is another user who just upgraded to Firefox 25 and is seeing a
> bunch of crashes, some of which are empty-dump and some of which are all
> over the place (maybe OOM crashes).

Another relevant one is bug 936784.  The bug reporter is seeing a
terrible memory leak (and subsequent crashes) in FF25.  In FF26 and
FF27 it has reduced to a much milder leak.  The bug reporter is very
responsive and gave me lots of additional info via private mail, but
unfortunately the relevant site is proprietary which blocked my
attempts at investigating further.

Anecdotally, my wife told me today that some people at her work were
complaining that FF25 used "way more" memory than previous versions.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform