<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">We've got "Reset Firefox" for that.
(available in <a class="moz-txt-link-freetext" href="about:support">about:support</a>, and there's talk of putting it in the
help menu in <a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=872240">https://bugzilla.mozilla.org/show_bug.cgi?id=872240</a> )<br>
<br>
~ Gijs<br>
<br>
On 13/03/2014 11:32, James May wrote:<br>
</div>
<blockquote
cite="mid:CABY6sLhLrOzhswp3Qa46ofhxwTXWwvS1iePf9bkbEJQ=Jbp-8g@mail.gmail.com"
type="cite">
<div dir="ltr">Perhaps "reset to defaults" should actually disable
the/all addons?<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 13 March 2014 03:12, Gijs Kruitbosch
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>So this wasn't so much a policy decision as much as
"this is what we always did".<br>
<br>
Most add-ons didn't modify the defaultset attribute, but
doing so would have done the same thing.<br>
<br>
We can identify some, but not all (ie, there are builtin
icons which will appear to be externally sourced),
builtin vs. add-on icons, and even that isn't
necessarily a useful distinction. If I install a
non-default toolbar like, say, the web developer
toolbar, all its icons will be non-default. It would
seem nonsensical to wipe out the contents of those
toolbars when resetting to defaults. We do hide them
when you hit 'restore defaults', but altering their
contents (other than resetting them to the defaults web
developer shipped with) would be unexpected, I would
have thought.<br>
<br>
So implementing this isn't terribly straightforward, the
current behaviour isn't a regression, and there are a
lot of other issues that need fixing before we ship. I
don't think we should prioritize changing this behaviour
this week, over the other P1/P2/P3 issues we have right
now.<span class="HOEnZb"><font color="#888888"><br>
<br>
~ Gijs</font></span>
<div>
<div class="h5"><br>
<br>
On 12/03/2014 16:36, Asa Dotzler wrote:<br>
</div>
</div>
</div>
<div>
<div class="h5">
<blockquote type="cite"> On 3/12/14, 8:13 AM, Madhava
Enros wrote:<br>
<blockquote type="cite">
<div style="font-size:10pt;font-family:Verdana">
<div>Yup - +1 to what Jared said. On install,
but not on hitting "Restore Defaults."<br>
</div>
<div><br>
Asa - nice to hear from you and thanks for
raising this!<br>
</div>
<div><br>
</div>
<div>Madhava<br>
</div>
</div>
</blockquote>
<br>
Great! Thanks for the quick replies, Jared and
Madhava. <br>
<br>
I found a bug! It's been a while. Feels good.
Thanks for filing the report, Jared.<br>
<br>
- A<br>
<blockquote type="cite">
<div style="font-size:10pt;font-family:Verdana">
<div><br>
</div>
<div><br>
</div>
<hr>
<div
style="font-size:12pt;font-style:normal;font-family:Helvetica,Arial,sans-serif;text-decoration:none;font-weight:normal"><b>From:
</b>"Jared Wein" <a moz-do-not-send="true"
href="mailto:jaws@mozilla.com"
target="_blank"><jaws@mozilla.com></a><br>
<b>To: </b><a moz-do-not-send="true"
href="mailto:firefox-dev@mozilla.org"
target="_blank">firefox-dev@mozilla.org</a><br>
<b>Cc: </b>"Asa Dotzler" <a
moz-do-not-send="true"
href="mailto:asa@mozilla.com"
target="_blank"><asa@mozilla.com></a><br>
<b>Sent: </b>Wednesday, March 12, 2014
10:53:41 AM<br>
<b>Subject: </b>Re: restore default toolbar
items and add-ons<br>
<div><br>
</div>
----- Original Message -----<br>
> From: "Asa Dotzler" <a
moz-do-not-send="true"
href="mailto:asa@mozilla.com"
target="_blank"><asa@mozilla.com></a><br>
> To: <a moz-do-not-send="true"
href="mailto:firefox-dev@mozilla.org"
target="_blank">firefox-dev@mozilla.org</a><br>
> Sent: Tuesday, March 11, 2014 9:21:47 PM<br>
> Subject: restore default toolbar items
and add-ons<br>
> <br>
> First, Australis is gorgeous! (and nicely
functional and fast and all<br>
> the other good things it's supposed to
be.) To those of you who have<br>
> been killing yourselves for years to make
this happen, wow, what a great<br>
> job. You're probably too deep in the few
tiny things that don't work<br>
> just right to see how great the view is
from a bit further away, so I'll<br>
> say it again, gorgeous!<br>
> <br>
> We have a great front end so thank you to
the front end folks who make<br>
> it happen.<br>
> <br>
> (I don't talk with y'all enough these
days and I figured I'd sneak in<br>
> some praise with my "concern.")<br>
> <br>
> With Australis we're finally going to
have a killer toolbar<br>
> customization story instead of that crap
that Joe and I left you with<br>
> about a decade ago. There's just one part
of it that's not taking care<br>
> of users first. We've given add-ons the
ability to claim to be part of<br>
> our default set of buttons. I think this
is wrong.<br>
> <br>
> Add-on toolbar buttons should not be
allowed to claim to be "default"<br>
> buttons and be restored to my toolbar
when I tell Firefox to "Restore<br>
> Defaults." This button should do what it
claims to do and what users<br>
> will expect it to do. It should undo what
everdamage has been done to<br>
> the user's toolbar, whether
self-inflicted or by way of a pushy add-on.<br>
> <br>
> I'm raising this here because I think
this is more of a policy question<br>
> than implementation issue. Also, to the
folks that implemented all of<br>
> this customization and restore
functionality and even the restore add-on<br>
> parts, it all seems to work great and I
think you did an excellent job.<br>
> I can't keep my mouse off of it :)<br>
> <br>
> - A<br>
<div><br>
</div>
Hi Asa,<br>
<div><br>
</div>
Thanks for sending this email. I agree with
you 100% that when we say "Restore Defaults"
we should be returning the browser UI to its
factory default state.<br>
<div><br>
</div>
However, I don't think this was so much as a
policy decision. In my eyes, it was more of an
oversight that some people like yourself are
just noticing now.<br>
<div><br>
</div>
Our API provides the ability for an add-on to
state where its widget should be placed by
default. This is currently interpreted as
where to place the button on install and on
restore.<br>
<div><br>
</div>
We should only respect this preference *on
install*, not on restore. Unfortunately, I
don't know if our API has the capability to
know if a widget was shipped with the browser
or is 3rd-party. I think that is the one
lacking bit of information that is holding us
back from achieving what you have asked for,
and it may not be too late to make this change
if we can get it in this week (since it won't
affect add-ons).<br>
<div><br>
</div>
Asa, I've taken the liberty of filing bug
982656 for you.<br>
<div><br>
</div>
Cheers,<br>
Jared<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:firefox-dev@mozilla.org"
target="_blank">firefox-dev@mozilla.org</a><br>
<a moz-do-not-send="true"
href="https://mail.mozilla.org/listinfo/firefox-dev"
target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
</div>
<div><br>
</div>
</div>
</blockquote>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
firefox-dev mailing list
<a moz-do-not-send="true" href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a>
<a moz-do-not-send="true" href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
firefox-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
<a moz-do-not-send="true"
href="https://mail.mozilla.org/listinfo/firefox-dev"
target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>