285696 - (suite-rebranding) Check in code for rebranding Mozilla for milestone releases

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Alex Vincent [:WeirdAl]]

Per the community agreement with the Mozilla Foundation, we (the community) will
be required to rebrand the Mozilla Application Suite for every release we make.
 We first need to identify all the places where such branding takes place
(splash screen, brand.dtd/properties, etc.).

After that (and once we have a confirmed name), we should start work (preferably
through the wiki so as to avoid extra bug attachments) on the various pieces of
art.  Similarly, we should start writing patches so that the rebranding can be
turned on by adding a single option to standard .mozconfig files (either a
./seamonkey/config/.mozconfig like file or a --enable-brand=seamonkey, or
something like that).

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

well, given that mf really has no interest in trunk seamonkey, why not just
change the branding stuff directly, without a configure option?

Comment 2

[Robert Kaiser]

Correct. If we don't need some trademark rules similar to what Firefox and
Thunderbird have, we don't need all those compiling switches, we just can check
in our new branding strings and artwork and be done with it.

In any case, this bug will cover whatever we have to do to get our new branding
in, either along with those build system things or not. We'll see that when the
name and trademark stories clear up.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

As expected, changing brand.dtd and .properties does not suffice. (Note: given
how it is used, it seems ok to change vendorShortName to "Seamonkey" as well)

NSS hardcodes "Mozilla": /security/nss/lib/ckfw/builtins/certdata.c, line 591 --
{ (void *)"Mozilla Builtin Roots", (PRUint32)22 }
that should probably be changed to "mozilla.org" or something

Installer hardcodes Mozilla in various places

So do environment variables, but we can probably ignore that, I think

/xpfe/bootstrap/nsAppRunner.cpp, line 154 -- #define MOZ_APP_NAME "mozilla"
and other places in this file will need to be patched


There'll be other things too... this is just what I saw at first sight.

Comment 4

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Asa, would it be reasonable to release future 1.8 betas under the community
branding?

Comment 5

[Robert Kaiser]

*** Bug 286065 has been marked as a duplicate of this bug. ***

Comment 6

[Zook Valem]

Reminder: Please remember to keep out the Godzilla-like images and/or wording
from this SeaMonkey build as to avoid the intellectual property information
(trademark) conflict and licensing issues as we had in the past.

Comment 7

[Robert Kaiser]

We should look into help as well when rebranding. Ideally, we have a correct
patch for bug 232794 landed before, but else we need to s/Mozilla/whatever there.

Comment 8

[Stefan [:stefanh]]

(In reply to comment #7)
> We should look into help as well when rebranding. Ideally, we have a correct
> patch for bug 232794 landed before, but else we need to s/Mozilla/whatever there.

"Mozilla" shouldn't be a problem to change without the patch, it's already an
entity (&brandShortName;). Of course we will then end up with "xxx mail &
Newsgroups" etc.

Comment 9

[Robert Kaiser]

Reminder for myself: check MailNews start page (including remove of standalone
tip), look through (X)HTML files living in locale/

Comment 10

[Robert Kaiser]

I've started preparing a patch but I'll wait for legal clearance on the name
before posting it.

Some notes about things that I still have not in my patch:

We should also update the release notes URL in those two files:
mozilla/xpfe/global/resources/locale/en-US/region.dtd
mozilla/xpfe/global/resources/locale/en-US/builtinURLs.rdf

and the default startup page in
mozilla/xpfe/browser/resources/locale/en-US/region.properties

I've not yet touched those files noted in comments here:
mozilla/security/nss/lib/ckfw/builtins/certdata.c
Installer (can someone tell me file names here?)
locale (X)HTML files

Comment 11

[Robert Kaiser]

Locale files that still contain a harcdoded "Mozilla"-Reference that should be
changed (no paths given at the moment, I'm retriveing data from L10n tool):
HtmlForm.properties (DefaultFormSubject)
filter.properties (cannotEnableFilter)
messenger.properties (filterFolderTruncateFailed)

Comment 12

[Robert Kaiser]

additionally, I found those:
communicator/search/default.htm
help/mozillahelp.rdf
help/help-toc.rdf
help/help-index1.rdf (?)

...and I still trusted the help XHTML files to have only hits because of the
copyright line...

Comment 13

[Robert Kaiser]

As I can't give you the patch yet, here's a list of files I'm touching right now:
mozilla/configure.in
mozilla/editor/ui/locales/en-US/chrome/region/region.properties
mozilla/extensions/help/resources/locale/en-US/mozillahelp.rdf
mozilla/extensions/help/resources/locale/en-US/help-toc.rdf
mozilla/mailnews/base/search/resources/locale/en-US/filter.properties
mozilla/mailnews/base/resources/content/start.xhtml
mozilla/mailnews/base/resources/locale/en-US/messenger.properties
mozilla/mailnews/base/resources/locale/en-US/region.properties
mozilla/mailnews/base/resources/locale/en-US/start.dtd
mozilla/profile/defaults/bookmarks.html
mozilla/xpfe/bootstrap/nsAppRunner.cpp
mozilla/xpfe/bootstrap/version.txt
mozilla/xpfe/bootstrap/browser-prefs.js
mozilla/xpfe/bootstrap/Makefile.in
mozilla/xpfe/browser/resources/locale/en-US/region.properties
mozilla/xpfe/communicator/resources/locale/en-US/brand.dtd
mozilla/xpfe/communicator/resources/locale/en-US/brand.properties
mozilla/xpfe/components/search/resources/locale/en-US/default.htm
mozilla/xpfe/global/resources/content/version.dtd
mozilla/xpfe/global/Makefile.in
mozilla/xpfe/global/resources/content/about.xhtml

What I haven't checked yet:
Installer (can someone tell me file names here?)

I haven't touched start page or release notes, see comment #10
I included a fix for the UA string though, so bug 286057 also gets fixed.

What I won't touch:
mozilla/security/nss/lib/ckfw/builtins/certdata.c
HtmlForm.properties (see bug 287695)

I also won't reach into Venkman, ChatZilla or Calendar (yet), though I've filed
bugs for their hardcoded strings. If you wonder, inspector has no hardcoded
"Mozilla" in the files I checked. Woo-hoo!

Comment 14

[John Dobbins]

It's been some time since I was in that area of the code, but I can give you a
partial list of Installer files.

There may be additional ones.

mozilla/xpinstall/packages-static-win
mozilla/xpinstall/packages-unix
mozilla/xpinstall/packages-win
mozilla/xpinstall/packager/build/cfgs/mozilla.pl
mozilla/xpinstall/packager/build/scripts/makecfgini.pl
mozilla/xpinstall/packager/build/scripts/makeuninstallini.pl
mozilla/xpinstall/packager/build/win/mozilla/defaults_info.ini
mozilla/xpinstall/packager/unix/makecfgini.pl
mozilla/xpinstall/packager/win_gre/config.it
mozilla/xpinstall/packager/win_gre/makecfgini.pl
mozilla/xpinstall/packager/win_gre/makeuninstallini.pl
mozilla/xpinstall/packager/win_gre/uninstall.it
mozilla/xpinstall/packager/windows/defaults_info.ini
mozilla/xpinstall/packager/windows/makeall.pl
mozilla/xpinstall/packager/windows/makecfgini.pl
mozilla/xpinstall/packager/windows/makeuninstallini.pl
mozilla/xpinstall/wizard/windows/builder/build.pl
mozilla/xpinstall/wizard/windows/builder/build_gre.pl
mozilla/xpinstall/wizard/windows/builder/build_mfcembed.pl
mozilla/xpinstall/wizard/windows/builder/build_static.pl

Comment 15

[Worcester12345]

Does it make sense to start looking at replacing the Netscape stuff at the same
time?

Comment 16

[Robert Kaiser]

(In reply to comment #15)
> Does it make sense to start looking at replacing the Netscape stuff at the same
> time?

If you find Netscape stuff that has to be replaced, maybe... I doubt there's any
left though (and referring to e.g Netscape 4.x migration is OK, just to remind
you)...

Comment 17

[Ian Neal]

The following files might need some work too:
/xpfe/bootstrap/nsNativeAppSupportBeOS.cpp
/xpfe/bootstrap/nsNativeAppSupportOS2.cpp
/xpfe/bootstrap/nsNativeAppSupportWin.cpp

Comment 18

[Robert Kaiser]

Attachment: patch stage 1: clean up some stuff and use MOZ_APP_* more often

OK, I got a first stage of the patch for you. This doesn't contain any real
branding change, but lots of stuff that makes the real rebranding easier.

And yes, it contains two small other things:
- Remove the "advertising" for Thunderbird from mailnews start page
- use correct URL for branding bundle in about.xhtml

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 178797 [details] [diff] [review]
patch stage 1: clean up some stuff and use MOZ_APP_* more often

+cannotEnableFilter=This filter was probably created by future version of this
software. You cannot enable this filter because we don't know how to apply it.

hm, ok. maybe the real name would be better here...

mozilla/xpfe/bootstrap/mozilla.man.in
+Print \fB/usr/bin/@MOZ_APP_NAME@-bin\fR version.

this is still wrong if $prefix != /usr... stuff below uses @bindir@, why not
use it here too?


Please don't check that GARBAGE line in xpfe/bootstrap/Makefile.in in with this
patch. I would prefer if rules.mk or somesuch handled it automatically.

nsAppRunner.cpp:
+  printf("%s %s, Copyright (c) 2003-2005 mozilla.org", MOZ_APP_DISPLAYNAME,
MOZ_APP_VERSION);

might be nice to also output the gecko version

mozilla/xpfe/bootstrap/macbuild/Contents/Info.plist.in

please get a mac person to review these changes, esp. CFBundleIdentifier


Now that about.xhtml no longer lives in /locale/, version.dtd can probably go
away; unless we want it for other reasons as well

r=biesi with at least the manpage change and removal of the GARBAGE line, and
review of Info.plist by a mac person

Comment 20

[[e-mail]]

Comment on attachment 178797 [details] [diff] [review]
patch stage 1: clean up some stuff and use MOZ_APP_* more often

Please fix up the grammar of cannotEnableFilter to say "by a future version".
Are those DEFINES supposed to be on separate lines?
Would you mind changing the bug reporting address to https: please?
You don't have to use %s to embed string contents in printf format strings, you
could use "literal" LITERAL concatenation (although I don't know what other
modules do).
Feel free to fix up the broken build id code.
Do we want to display the Gecko version in about: ? Former Suite users might
want to know ;-)

Comment 21

[Stefan Persson]

(In reply to comment #20)
> Do we want to display the Gecko version in about: ? Former Suite users might
> want to know ;-)

Isn't the Gecko version the "rv" part of the Browser line?  The "rv" part is
there in both Mozilla and Firefox:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Will the "rv" part be removed in the new suite?  I guessed that the browser line
would just be something like

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/YYYYMMDD SomeSecretName/1.0

(i.e. with the only change being that the name and version number are added at
the end of the line)

The browser line is included on the about: page, so would it really be necessary
to mention the Gecko version elsewhere too?

Comment 22

[Simon Fraser [no longer active]]

r=sfraser on the mac parts of the patch.

Comment 23

[Robert Kaiser]

(In reply to comment #19)
> hm, ok. maybe the real name would be better here...

For one thing, this is a rarely shown text (only when we change the filter
interface and an older version tries to use it again), for the other, if we
would be correct there, we'd need to list all possible product names that thise
future version can have, and I decided extending it to even
"SeaMonkey/Thunderbird/Mozilla/Netscape" would look very strange to a user.

> mozilla/xpfe/bootstrap/mozilla.man.in
> +Print \fB/usr/bin/@MOZ_APP_NAME@-bin\fR version.
> 
> this is still wrong if $prefix != /usr... stuff below uses @bindir@, why not
> use it here too?

I think the stuff below might be wrong in case of prefix things as well, but I
updated it to use the same path for @MOZ_APP_NAME@-bin as below. good catch :)

> Please don't check that GARBAGE line in xpfe/bootstrap/Makefile.in in with this
> patch. I would prefer if rules.mk or somesuch handled it automatically.

OK, I'll exclude it for now and talk to bsmedberg if we really need it.

> nsAppRunner.cpp:
> +  printf("%s %s, Copyright (c) 2003-2005 mozilla.org", MOZ_APP_DISPLAYNAME,
> MOZ_APP_VERSION);
> 
> might be nice to also output the gecko version

We can probably add that later, if wanted. It should be easy.

> mozilla/xpfe/bootstrap/macbuild/Contents/Info.plist.in
> 
> please get a mac person to review these changes, esp. CFBundleIdentifier

OK, I hope to find one...

> Now that about.xhtml no longer lives in /locale/, version.dtd can probably go
> away; unless we want it for other reasons as well

Hmm, good idea, I'll look into that in stage 2 (so that I can do some testing
before it lands)

(In reply to comment #20)
> Please fix up the grammar of cannotEnableFilter to say "by a future version".

Done.

> Are those DEFINES supposed to be on separate lines?

Should I better only write the "DEFINES +=" once and use \ at the line endings
to concatenate them all at once? I think I can't stick them into one line
anyways without breaking the 80-character barrier...

> Would you mind changing the bug reporting address to https: please?

Sure. Done.

> You don't have to use %s to embed string contents in printf format strings, you
> could use "literal" LITERAL concatenation (although I don't know what other
> modules do).

Well, I just used the style of nsAppRunner.cpp - as I'm not really experienced
with C++ (yet), I'd gladly use any other style if someone shows me how to do it ;-)

> Feel free to fix up the broken build id code.

Sure. Where? How? Well, perhaps I might really look into this later, when all
that rebranding stuff is done... :)

> Do we want to display the Gecko version in about: ? Former Suite users might
> want to know ;-)

Well, we display the full UA string, which contains the Gecko version. Is that
enough? Should we make it more visible? In which way?

Comment 24

[Robert Kaiser]

Attachment: patch stage 1, review nits fixed (checked in)

OK, this is the stage 1 patch with the review nits fixed.
I still need input if it builds OK on windows and mac before I check it in
though (linux was tested by me and doron).

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #23)
> we'd need to list all possible product names that thise
> future version can have, and I decided extending it to even
> "SeaMonkey/Thunderbird/Mozilla/Netscape" would look very strange to a user.

Well, just using brandShortName should be ok, and is what I meant... But that
may be hardish to implement.
 
> > You don't have to use %s to embed string contents in printf format strings, you
> > could use "literal" LITERAL concatenation (although I don't know what other
> > modules do).

neil: I'm realizing that apprunner seems to already use %s for HELP_SPACER_n,
which is also a #define...

Comment 26

[Alex Vincent [:WeirdAl]]

(In reply to comment #24)
> OK, this is the stage 1 patch with the review nits fixed.
> I still need input if it builds OK on windows and mac before I check it in
> though (linux was tested by me and doron).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050328
It compiles just fine.

Comment 27

[[e-mail]]

(In reply to comment #24)
>I still need input if it builds OK on windows
It built under mingw using make -s -C objdir/mailnews realchrome && make -s -C
objdir/xpfe/bootstrap libs && make -s -C objdir/xpfe/global realchrome

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

works fine on windows xp, msvc.net. mozilla -version and help/about mozilla look
right.

Comment 29

[Martin Creutziger [:MMx]]

Comment on attachment 178870 [details] [diff] [review]
patch stage 1, review nits fixed (checked in)

applied this patch to 2005-03-28 CVS code and it builds and runs fine on Mac 
OS X.

Comment 30

[Robert Kaiser]

Comment on attachment 178870 [details] [diff] [review]
patch stage 1, review nits fixed (checked in)

OK, stage 1 is checked in, let's move forward!

Comment 31

[Stefan Persson]

Shouldn't https://bugzilla.mozilla.org/show_bug.cgi?id=244672 (and possibly also
https://bugzilla.mozilla.org/show_bug.cgi?id=243575) be added to the list of
bugs this depends on?

Comment 32

[Robert Kaiser]

The name of our application does not affect bug 243575, our rebranding is
independent from that one. Bug 244672 is a good point and would be nice to have
in that effort, but we won't block the alpha for it (same with a bunch of other
dependencies though)...

Comment 33

[Mark Banner (:standard8)]

Attachment: Fix Man Page

As discussed with Kairo earlier today, this patch fixes the manual page found
in mozilla/xpfe/bootstrap that was broken by the stage 1 patch - basically some
variables weren't being replaced, and the paths were wrong so we've set them to
the default unix installation paths for now.

Comment 34

[Robert Kaiser]

Comment on attachment 179393 [details] [diff] [review]
Fix Man Page

r- via IRC. We should better use the configured prefix (mozappdir) that we
install to with "make install". That way some distro can use standard configure
options and get a correct man file (I hope).

Comment 35

[Mark Banner (:standard8)]

Attachment: Revised fix for Man Page

Revised patch to use mozappdir.

Comment 36

[Robert Kaiser]

Comment on attachment 179410 [details] [diff] [review]
Revised fix for Man Page

Yes, looks good to me this way.

Comment 37

[Mark Banner (:standard8)]

Comment on attachment 179410 [details] [diff] [review]
Revised fix for Man Page

Sorry folks, I got this wrong again, make install installs the wrapper script
into bindir & the executable into mozappdir.
New patch coming.

Comment 38

[Mark Banner (:standard8)]

Attachment: Revised fixed for man page 2 (checked in)

Ok, this one matches where things go when we do a make install.

Comment 39

[Robert Kaiser]

Comment on attachment 179417 [details] [diff] [review]
Revised fixed for man page 2 (checked in)

OK, this seems to be where builds really go to for "make install" (and I guess
that's what most distributors do to create their packages)

Comment 40

[Robert Kaiser]

Comment on attachment 179417 [details] [diff] [review]
Revised fixed for man page 2 (checked in)

Manpage fix checked in.

Comment 41

[Robert Kaiser]

Attachment: stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in)

Looking through the recently checked in patch for bug 274928 and applying that
approach to our stuff, I realised we have to get rid of the \"$(MOZ_APP_NAME)\"
trickery in bootstrap's Makefile.in and instead use NS_STRINGIFY() in the .cpp,
just like dbaron did there, so we can stuff those strings into the UA without
problems (see bug 286057).
This patch does exactly that.

Comment 42

[Robert Kaiser]

Attachment: stage 1, additional fix 2: remove version.dtd (checked in)

As biesi has requested it in his review nits for stage 1, and we still have to
wait for a complete solution, I hacked up the removal of version.dtd and
preprocessing of about.xhtml instead.

Comment 43

[Stefan Persson]

How does MOZ_APP_DISPLAYNAME work with different forms of the name in different
languages?  For example, assume the following two MOZ_APP_DISPLAYNAMEs:

Mozilla: Swedish genitive = Mozillas (i.e. an 's' is added)
Firefox: Swedish genitive = Firefox' (i.e. an apostrophe is added)

More complex modifications are likely to be needed in languages with more forms
of names.

Comment 44

[Robert Kaiser]

Comment on attachment 180057 [details] [diff] [review]
stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in)

requesting approval: seamonkey-only fix so that we can use the new vendor
additions for UA

Comment 45

[Robert Kaiser]

Comment on attachment 180058 [details] [diff] [review]
stage 1, additional fix 2: remove version.dtd (checked in)

requesting approval: seamonkey-only cleanup of about page code

Comment 46

[Robert Kaiser]

(In reply to comment #43)
> How does MOZ_APP_DISPLAYNAME work with different forms of the name in different
> languages?  For example, assume the following two MOZ_APP_DISPLAYNAMEs:

MOZ_APP_DISPLAYNAME is set at build time and is not localizable, nor are
practially all strings it's used in (help text of the mozilla binary etc). All
localizable content is supposed to use chrome's branding stuff.

Comment 47

[Asa Dotzler [:asa]]

Comment on attachment 180057 [details] [diff] [review]
stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in)

a=asa

Comment 48

[Asa Dotzler [:asa]]

Comment on attachment 180058 [details] [diff] [review]
stage 1, additional fix 2: remove version.dtd (checked in)

a=asa

Comment 49

[Robert Kaiser]

Comment on attachment 180058 [details] [diff] [review]
stage 1, additional fix 2: remove version.dtd (checked in)

Both additional fixes for stage 1 checked in.
I hope we'll get clearance on the name soon so I can get to stage 2 a.k.a. "the
real thing" :)

Comment 50

[alanjstr]

Once you guys have your rebranding worked out, we'll work on getting you onto UMO.

Comment 51

[Peter Weilbacher]

I don't see a bug about the splash screen? That needs to be rebranded, right?
(And perhaps change color to fit the new logo whatever that may be.)

Comment 52

[Robert Kaiser]

(In reply to comment #51)
> I don't see a bug about the splash screen? That needs to be rebranded, right?
> (And perhaps change color to fit the new logo whatever that may be.)

Artwork will be resolved after the alpha release, we'll take user submissions
for a logo, and the final splash screen will be created after we have such a
logo. We'll use some very primitve placeholder artwork for the alpha for the
time being, as we can't do a logo contest or something like that when we have no
publicly announced name yet.

Comment 53

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Anything we need to do about this NetCenter junk?
http://lxr.mozilla.org/seamonkey/search?string=netcenter

Comment 54

[Robert Kaiser]

Attachment: stage 2: do the real rebranding

OK, this is the real thing now.

Please DON'T shout out loud about it for now (_no_ blog entries, board threads
or similar stuff yet), we're preparing an official announcement for going
public with the name, and we want that to hit the news, not some random
bugzilla report and patch.

So, consider this patch unofficial as long as there's no announcement about a
new suite project with a new name out there.

Regarding the artwork: Most of the patch size is the splash.xpm image, and the
patch mentions quite some "binary" image files that will all have that
temporary placeholder artwork contributed by Chris Thomas. This WON'T be our
official artwork for 1.0, we'll open a channel for artwork/logo submissions
soon after going public.

Comment 55

[Robert Kaiser]

Comment on attachment 187687 [details] [diff] [review]
stage 2: do the real rebranding

requesting approval: suite-only change to rebrand trunk to use the new
"SeaMonkey" name throughout the product.

Comment 56

[Benjamin Smedberg]

Comment on attachment 187687 [details] [diff] [review]
stage 2: do the real rebranding

a=bsmedberg

Comment 57

[Robert Kaiser]

OK, we're ready to go code/patch-wise, but Chase is overloaded currently (no
time before the july 4 holiday) and can't do the infrastructure stuff atm.

We have to coordinate bugs 292268,285696,288199,289846,298901 to make it all
happen at once and make the transition as smooth as possible, so we'll push out
the whole thing a few days (this is all SeaMonkey-only so we don't have to care
about aviary 1.1a2 too much), I hope it'll be ASAP - still need to schedule an
impact date/time with Chase though.

Additionally, we'll have to wait a few days as well to get MoFo reviews on the
announcement which should go public in a tight timeframe around the happening of
those changes.
Please be warned it's coming up but patient at the same time.

Comment 58

[Robert Kaiser]

OK, stage 2 has landed and this bug should be fixed. :)

Note that Chase is working on resolving the tinderbox problems and
infrastructure changes with us right at this moment, and we're still waiting on
a review and OK for our announcement from Mozilla Foundation people (we're
talking about our realtion to them in there, so they need to sanction it).

Please wait just a bit longer until that's all done (trees green, builds
appearing at new places, announcement and new project page up at
http://www.mozilla.org/projects/seamonkey/ ) before shouting the message out
publicly.

It should hopefully be a matter of hours to days until we're set up completely.
Thanks for your patience and we hope to have a good future with that new,
rebranded product!

Comment 59

[jag (Peter Annema)]

Any idea why this made Tp on btek go up from 835ms to 905ms?

Comment 60

[Boris Zbarsky [:bzbarsky]]

I bet the new throbber is a lot slower to animate.  Could someone please test
that by backing out the new throbber and seeing what btek does?

Comment 61

[Christian :Biesinger (don't email me, ping me on IRC)]

throbber changes backed out

Comment 62

[Boris Zbarsky [:bzbarsky]]

Well, that doesn't seem to have been it... what else could have changed?

Comment 63

[Christian :Biesinger (don't email me, ping me on IRC)]

throbber changes relanded...

Comment 64

[Robert Kaiser]

(In reply to comment #60)
> I bet the new throbber is a lot slower to animate.

Interestingly, the new placeholder throbber is even smaller in size than the old
one (which doesn't have to affect Tp directly).
What makes me wonder is that luna has no Tp changes at all.

Anyways, could we take discussion about the btek Tp problem and about Z changes
(which I'd like to have investigated as well) to a new bug?

Comment 65

[Christian :Biesinger (don't email me, ping me on IRC)]

I have to note... what I tried was classic throbber, but it looks like tbox may
actually be testing modern. someone should try backing out modern throbber.

Comment 66

[Boris Zbarsky [:bzbarsky]]

I'm fine with a new bug if it's marked blocker.  An 8% Tp regression is pretty
unacceptable...

Comment 67

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #65)
> I have to note... what I tried was classic throbber, but it looks like tbox may
> actually be testing modern. someone should try backing out modern throbber.

I backed it out.

Comment 68

[Robert Kaiser]

Modern throbbers are back in, they also had no effect.

I filed bug 299624 for the btek Tp increase, and bug 299627 on the codesize
increase.

Comment 69

[Hixie (not reading bugmail)]

This checkin affected the about:logo image for Camino. Please to be fixing ASAP.

Comment 70

[Mike Pinkerton (not reading bugmail)]

yeah, what on earth is going on here?

Comment 71

[Robert Kaiser]

(In reply to comment #69)
> This checkin affected the about:logo image for Camino. Please to be fixing ASAP.

Filed as bug 299897

Comment 72

[Zook Valem]

What about bug #271745.  Something we need to do about it??