Re: Converting assertions into release assertions

[Wayne]

On 9/22/2016 12:28 AM, Nicholas Nethercote wrote:

Greetings,

Assertions, such as MOZ_ASSERT, are great. But they only run in debug builds.

Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.

I want to highlight a nice case where converting a normal assertion
into a release assertion was a win. In bug 1159244 Michael Layzell did
this in nsTArray::ElementAt(), to implement a form of always-on array
bounds checking. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1159244#c55 for
discussion of how this is finding real bugs in the wild. (As well as
identifying new bugs, it's also helping understand existing crash
reports, e.g. see bug 1291082 where the crash signature changed.)

Obviously we can't convert every normal assertion in the codebase into
a release assertion. But it might be worth thinking about which normal
assertions are good candidates for conversion. Good candidates include
any assertion where the consequence of failure is dangerous, e.g.
might cause memory access violations.

Nick


For grins I ran the socorro query from the bug report against 
Thunderbird 
https://crash-stats.mozilla.com/search/?moz_crash_reason=~ElementAt=Thunderbird&_sort=-date&_facets=signature&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature


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

All profile settings lost in new version

[Wayne]

I'm wondering, under what circumstances would a user have a prefs.js-1 
and prefs.js be missing?


ref https://support.mozilla.org/en-US/questions/1136992
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Leaving hg.mozilla bug.mozilla to github for the leaving complicated infrastructure of mozilla.

[Wayne]

On 12/4/2015 3:06 AM, 罗勇刚(Yonggang Luo)  wrote:

When I trying submit a patch to thunderbird community, that's always need
to create a
bug in bug.mozilla.org, and that's very hard to use and slow.
The merging progress are very slow. That's why I am hesitate to
contributing things back.


Do you a guess of _why_ they are slow?
How serious is the slowness?
How much faster would it need to be to be acceptable?


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

Re: Stepping down as the module owner of editor/

[Wayne]

On 10/22/2015 9:14 AM, Ehsan Akhgari wrote:

On 2015-10-22 4:53 AM, Jörg Knobloch wrote:

On 22/10/2015 02:49, Ehsan Akhgari wrote:

I think it's
time for me to step down as the owner of editor/.


Sad to hear and thank you for your work.

Is there a list of unowned modules? Recently I heard that the serializer
code is also practically unowned. That's located in dom/base.


There is a list for Core at the end of
.


What is Mozilla's policy on this in general? How is it possible that
vital parts of Gecko are unowned?


I don't think if we have a specific policy.  Usually the reason is
limited resources as one might expect.



Perhaps what equally hurts editor more generally, and what has impacted 
your decision in particularly, is the lack of peers on this module to 
share the load.


Kudos for Ehsan taking the module in 2011 when it languished without any 
owner or peers.

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

Re: Voting in BMO

[Wayne]

On 6/9/2015 6:00 PM, Justin Dolske wrote:

On 6/9/15 2:24 PM, Chris Peterson wrote:


I vote for bugs as a polite (sneaky?) way to watch a bug's bugmail
without spamming all the other CCs by adding myself to the bug's real
CC list.


I think if Bugzilla, with its long and complex history, ever has a hope
of being untangled into something better, we can't keep every feature
because of all the possible ways it might be used. :)

Here, I'd suggest that the default should be to _not_ send emails for CC
changes, unless a user opts into it (and maybe even not even for that,
it's just spammy for anyone managing lots of bugs. But baby steps...).
Net improvement, no matter what happens with voting.

I'd agree that voting could be removed. Most people know that it was
added as a way to counter +1! type comments.


I've never heard such a thing. However, if it does that, then it does 
have a purpose - one that I'd just as soon keep until an alternative is 
offered that doesn't require monitoring and work. (which tagging, 
mentioned below, does require)



But I'd counter that (1)
it's unclear that it's very effective in that role and (2) I've rarely
actually seen people telling people to use voting.


(1) may be true only for projects that don't use it.  (2) should held 
against the feature because ___?




We have better tools now with the ability to tag and hide comments
(https://wiki.mozilla.org/BMO/comment_tagging) which I _do_ see used
frequently, as well as the ability to entirely disable commenting on
bugs in extenuating circumstances. I'd like to see those further improved.


We can all agree we'd rather not see unhelpful comments nor have to deal 
with them.  Personally I'd rather not have to tag unuseful comments.




That said, there are much bigger issues with Bugzilla's UI, and removing
voting is probably the smallest possible improvement. But it's probably
easy to just disable it for a while, and see what happens?


I never have seen the voting UI as being the least bit distracting. So 
I'd completely agree, other things in the UI are FAR more deserving of 
attention and discussion.


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

Re: e10s is now enabled by default for Nightly!

[Wayne]

On 11/6/2014 7:27 PM, Chris Peterson wrote:

The patch is on mozilla-inbound and ought to hit mozilla-central in time
for tomorrow's Nightly build. \o/

https://hg.mozilla.org/integration/mozilla-inbound/rev/a75897e664dd

e10s will not ride the trains to Aurora 36. Talos and unit tests will
continue to run for e10s and non-e10s until e10s hits the Release channel.

Some known problems:

* IME and a11y will disable e10s until support is completed
* Some performance problems with Adblock Plus
* Bug  947030 - Ghostery add-on does not block trackers
* Bug  972507 - BugzillaJS add-on does not work [1]
* Bug 1008768 - LastPass add-on does not fill in form fields
* Bug 1014986 - HTTPS Everywhere add-on breaks HTTP redirects
* Bug 1042680 - Tree Style Tabs add-on does not work
* Bug 1042195 - 1Password add-on does not work
* Bug 1058542 - NoScript add-on does not work
* Bug 1093161 - Searching from address bar does not work the first time


Bug 1067042 - [e10s]bookmarking an e10s tab results in a blank name

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

Re: Upcoming changes to autocomplete code affecting Thunderbird

[Wayne]

please note that followups are set to m.dev.platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming changes to autocomplete code affecting Thunderbird

[Wayne]

please note that followups are set to m.dev.platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [RFC] Cleaning up sessionstore.js

[Wayne]

On 11/28/2013 6:15 PM, Matthew N. wrote:

On 11/28/13, 7:15 AM, Honza Bambas wrote:

On 11/28/2013 12:56 PM, David Rajchenbach-Teller wrote:

As many of you know, Session Restore is something of a performance hog,
for many reasons – we have reports of. One of the reasons is that we
store so very many things in sessionstore.js and sometimes keep stuff
for a very long time.


Do we know that these issues affect a large number of users and not just
tab hoarders like myself?


So, here are a few things that I believe we could cleanup:
1. get rid of closed windows after a while;

Definitely, also from a privacy POV.

2. get rid of closed tabs after a while;

Ditto

3. get rid of old history entries of open tabs after a while;
4. get rid of POST data of history entries after a while;
5. get rid of DOM storage contents of open tabs after a while;
6. get rid of form data content of open tabs after a while;

4-6: from a user POV - I have to agree also with Till, I really like
that form data are not lost *for ages*, I always write a bug report and
then leave it unsent to collect more data first, as well as any bug
comments.  And I'm really enjoying how well Fx keeps these data
unbroken.  That should stay.


I agree that #1 and #2 should expire but I don't think expiring 3-6 is
worth the loss of functionality and trust in the browser. Fixing #1 and
#2 would also probably reduce the need for 3-6 since the browser default
is to open the homepage on every launch instead of restoring the session
and we know that most users don't change defaults.

It's not uncommon for me to go back to a tab group for a side project
that I haven't worked on for a few months and want to resume where I
left off. #3, #4, and #6 would definitely hinder that. It's hard to say
if #5 would without knowing how websites are using DOM storage. To be
clear, is that just referring to window.sessionStorage?

Cheers,
Matthew N. [:MattN]


I have similar workflow and would also consider 3-6 to be dataloss.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform