Closed Bug 715557 Opened 13 years ago Closed 13 years ago

Refresh Thunderbird-specific code of titlebar customization in NTT 3.x

Categories

(Other Applications Graveyard :: Nightly Tester Tools, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: xabolcs, Assigned: xabolcs)

References

()

Details

Attachments

(6 files, 3 obsolete files)

Thunderbird support of was "discounted" in NTT 3.0 by Bug 612684.
See https://github.com/mozilla/nightlytt/commit
/5aa61340c5b817be39a1620e6886842713afc16f

The legacy code is compatible with Gecko 1.9 and below due it's setTitleFromFolder() overriding [1].

In Thunderbird 3 the tabmail[2] introduced and it gets closer to the Firefox code.
It now uses setDocumentTitle() [3].


I implemented in a way the new title customizing: 
I tried not to change the customizer logic.

I am going to create a pull request for it.


Thanks,
Szabolcs


[1] - https://mxr.mozilla.org/firefox/source/mail/base/content/commandglue.js#94
[2] - https://developer.mozilla.org/En/Thunderbird_3_for_developers#Tabbed_mail
[3] - https://mxr.mozilla.org/comm-1.9.1/source/mail/base/content/tabmail.xml#1093
Assignee: nobody → xabolcs
@xabolcs: that patch looks quite extensive to me. I think you should go through the normal Mozilla routine: ASSIGN the bug to yourself (i.e. change the status to ASSIGNED), attach a unified diff to this bug after making sure that it is unbitrotten, have that patch reviewed and possibly (Heather, what do you think? and who would you suggest as reviewer / superreviewer for this kind of patch?) superreviewed, and only after you get r+ (and possibly sr+) request a pull by setting the "checkin-needed" flag on this bug (only then would be the right time for a corresponding pull request at github).

Having the bug reviewed (and, depending on the nature of both the bug and the code it touches) is not a hazing: even patches proposed by the most experienced and respected Mozilla coders go through the same routine. The idea is "the more eyes on a patch, the fewer bugs left in it".
oops, forgot the word "superreviewed" after the last ) in the previous comment.
(In reply to Tony Mechelynck [:tonymec] from comment #1)

It's OK with Mozilla routine, I read some Wiki / blog post so I try to do my best with patches. :)
By the way I have no ASSIGNED option in Status, just UNCONFIRMED and RESOLVED.
My permission bits are only one: everyone
So I can't take the other bug too: Bug 703208


I'll attach a patch soon.
Attached patch Renew legacy Messenger code v1 (obsolete) — Splinter Review
In this v1 patch I did:
1. leave the business logic untouched except the override
2. renamed the functions to be consistent with the implemetation: setTitleFromFolder -> tabmailSetDocumentTitle


About the override:
The old code simply overrides the window.setTitleFromFolder function.
But in the newer TB there are no setTitleFromFolder in window, as the Extension Test addon [1] pointed out.

So I changed the logic slightly - manipulate the "titlemodifier" attribute of the window, and update titles only if the used feature exists.

By the way should NTT have so much global variable?



[1] - https://addons.mozilla.org/thunderbird/addon/extension-test/
Attachment #586609 - Flags: review?
Repacked version of the 60~70k sized NTT 3.2.1 from AMO.
Included:
- patched messenger.js and messengerOverlay.xul
- the platform directory, recursively! It was left out from the release.

Please note that somebody need to re-upload the xpi in AMO, because the applications miss the binary components!
Attachment #586618 - Flags: feedback?
Attachment #586618 - Attachment mime type: application/octet-stream → application/x-xpinstall
Attachment #586609 - Attachment description: Renew legacy Messenger code → Renew legacy Messenger code v1
(In reply to Szabolcs Hubai from comment #3)
> (In reply to Tony Mechelynck [:tonymec] from comment #1)
> 
> It's OK with Mozilla routine, I read some Wiki / blog post so I try to do my
> best with patches. :)
> By the way I have no ASSIGNED option in Status, just UNCONFIRMED and
> RESOLVED.
> My permission bits are only one: everyone
> So I can't take the other bug too: Bug 703208

OK, I'll do it for you.

> 
> 
> I'll attach a patch soon.

In reply to comment #4 and #5
Requesting a review or a feedback from "the wind" is usually not very effective, but we'll see what we can do. Heather, do you feel up to checking this patch and giving a detailed review (I don't), or shall we try and find another reviewer?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment on attachment 586609 [details] [diff] [review]
Renew legacy Messenger code v1

Review of attachment 586609 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the patch! Does this require changing the versions numbers of Thunderbird that NTT supports in install.rdf?

::: chrome/content/messenger.js
@@ +41,5 @@
>  
> +storedTitleModifier: document.documentElement.getAttribute("titlemodifier"),
> +storedTitleMenuSeparator: document.documentElement.getAttribute("titlemenuseparator"),
> +
> +savedTabmailSetDocumentTitle: document.getElementById("tabmail") && typeof(document.getElementById("tabmail").setDocumentTitle) === "undefined" ? null : window.document.getElementById("tabmail").setDocumentTitle,

These var names are pretty long, but it seems like they're going along with the theme.

@@ +90,3 @@
>  {
> +  
> +  nightlyApp.customTitleModifier = nightlyApp.customTitle.substring(nightlyApp.customTitle.indexOf(nightlyApp.storedTitleMenuSeparator)+nightlyApp.storedTitleMenuSeparator.length);

We'll need to put some newlines in here after 80 chars.
Attachment #586609 - Flags: review? → review+
(In reply to Tony Mechelynck [:tonymec] from comment #1)
> (Heather, what do you think? and who would you suggest as reviewer / superreviewer for this
> kind of patch?) superreviewed, and only after you get r+ (and possibly sr+)
> request a pull by setting the "checkin-needed" flag on this bug (only then
> would be the right time for a corresponding pull request at github).

We shouldn't need superreview for anything to do with NTT. It's good to have something like this in a patch. I do think simple pull requests could simply be merged though, at your or any other owner's discretion.
(In reply to Heather Arthur [:harth] from comment #8)
> (In reply to Tony Mechelynck [:tonymec] from comment #1)
> > (Heather, what do you think? and who would you suggest as reviewer / superreviewer for this
> > kind of patch?) superreviewed, and only after you get r+ (and possibly sr+)
> > request a pull by setting the "checkin-needed" flag on this bug (only then
> > would be the right time for a corresponding pull request at github).
> 
> We shouldn't need superreview for anything to do with NTT. It's good to have
> something like this in a patch. I do think simple pull requests could simply
> be merged though, at your or any other owner's discretion.

OK. The reason I do it "by the book" (especially when I don't understand the patch) is two have at least two pairs of eyes (reporter and reviewer) check the patch, to reduce the risk of a bug creeping in. But since you OK this patch, let's push it...

Ah yes, I forgot, there was a merge conflict. Szabolcs (or is it Hubai? I know that the Hungarian custom is to write the family name first, but not always when writing in English), would you please prepare an unbitrotten version of the patch? (i.e. pull mozilla/nightlytt branch "master" into your fork, or maybe [your choice] make a new fork, then apply the patch there, resolve any merge conflicts, and _then_ submit a new pull request)? I suppose (but, Heather, please speak up if you disagree) that if the patch is still "recognisably" the same you may carry-over the r+ and set the "checkin-needed" on the bug then. Whatever patch you submit should in any case apply cleanly on top of the latest commit on the master branch.


See also https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide but remember that if a given source file uses a consistent style, you should follow the existing style in the file even if it disobeys the Style Guide. (This said, the original NTT developer was Mossop, a Mozilla developer of good standing, and I'm confident that he didn't stray away from the "house style" unless he had a very good reason.)


I see you're enthusiastic. Good! The project needs more such people. After you fix a few bugs (the theoretical minimum is two) and of course if they don't introduce serious regressions, you'll be entitled to apply for EDITBUGS privileges. Beware though, that with increased power comes increased responsibility (which starts with a duty not to misuse that new power). Relevant pages about Bugzilla privileges are:
https://developer.mozilla.org/en/What_to_do_and_what_not_to_do_in_Bugzilla
http://www.gerv.net/hacking/before-you-mail-gerv.html
Good luck! (or rather, don't trust luck, trust a diligent study of the code ;-) ).
(In reply to Tony Mechelynck [:tonymec] from comment #6)
> [...]
> In reply to comment #4 and #5
> Requesting a review or a feedback from "the wind" is usually not very
> effective, but we'll see what we can do. [...]

Sorry for my english, but I do not really understand what does the "requesting something 'from the wind'" mean. Could You explain this?




(In reply to Heather Arthur [:harth] from comment #7)
> Comment on attachment 586609 [details] [diff] [review]
> Renew legacy Messenger code v1
> 
> Review of attachment 586609 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thanks for the patch! Does this require changing the versions numbers of
> Thunderbird that NTT supports in install.rdf?
> 

Since NTT 2.0 the TB compatibility was always more than TB 3.0, 
therefore I removed the old code while adding the new code.
If you want to extend the compatibility below 3.0 then somebody have to
specify how to implement the two customizing method side by side.
Anyway, I've some ideas. :)

By the way, the answer is, you don't need to change the compatibility numbers for Thunderbird. If somebody test all the NTT features (not just this titlebar customizing) with TB3.0. The TabMail introduced in TB3, as wrote in the comment 0, so this should work with it.
Note that I tested this patch with 3.1 and Earlybird (currently: 11).


> ::: chrome/content/messenger.js
> @@ +41,5 @@
> >  
> > +storedTitleModifier: document.documentElement.getAttribute("titlemodifier"),
> > +storedTitleMenuSeparator: document.documentElement.getAttribute("titlemenuseparator"),
> > +
> > +savedTabmailSetDocumentTitle: document.getElementById("tabmail") && typeof(document.getElementById("tabmail").setDocumentTitle) === "undefined" ? null : window.document.getElementById("tabmail").setDocumentTitle,
> 
> These var names are pretty long, but it seems like they're going along with
> the theme.
> 

if I have not chosen these names, I would have chosen a nightlyApp.tabmail object with some properties and functions.


> @@ +90,3 @@
> >  {
> > +  
> > +  nightlyApp.customTitleModifier = nightlyApp.customTitle.substring(nightlyApp.customTitle.indexOf(nightlyApp.storedTitleMenuSeparator)+nightlyApp.storedTitleMenuSeparator.length);
> 
> We'll need to put some newlines in here after 80 chars.

Breaks like these, will OK?

customTabmailSetDocumentTitle: function(aTab)
{
  
  nightlyApp.customTitleModifier = nightlyApp.customTitle.substring(
      nightlyApp.customTitle.indexOf(nightlyApp.storedTitleMenuSeparator)
      + nightlyApp.storedTitleMenuSeparator.length
  );
  document.documentElement.setAttribute("titlemodifier", nightlyApp.customTitleModifier);
  

Hmm.... and for savedTabmailSetDocumentTitle? It have a long line too!
Could you comment this below?

savedTabmailSetDocumentTitle: 
  document.getElementById("tabmail") && 
  typeof(document.getElementById("tabmail").setDocumentTitle) === "undefined" 
  ? null 
  : window.document.getElementById("tabmail").setDocumentTitle,
tabmailSetDocumentTitle: null,



(In reply to Tony Mechelynck [:tonymec] from comment #9)
> 
> Ah yes, I forgot, there was a merge conflict. Szabolcs (or is it Hubai? I
> know that the Hungarian custom is to write the family name first, but not
> always when writing in English), would you please prepare an unbitrotten
> version of the patch? (i.e. pull mozilla/nightlytt branch "master" into your
> fork, or maybe [your choice] make a new fork, then apply the patch there,
> resolve any merge conflicts, and _then_ submit a new pull request)? I
> suppose (but, Heather, please speak up if you disagree) that if the patch is
> still "recognisably" the same you may carry-over the r+ and set the
> "checkin-needed" on the bug then. Whatever patch you submit should in any
> case apply cleanly on top of the latest commit on the master branch.
> 
> 

Hmmm, really, there was conflicts? :(
I started from Heather's "update readme for new markdown parser" commit 
with some version bumping commits, and continued with this patch.
As I said the Mozilla method will OK, I'm happy if I receive some r+ in Bugzilla. :)

Hehh, you are good! As we are in english environment here, so I'm Szabolcs. :)

This v1 patch was started from your "Merge pull request #12 from tonymec/master" commit. I hope it applies cleanly.
If I would make a pull req again, I will pull all from mozilla/master before it.


Hmmm, this comment get too long, sorry for it.
(In reply to Szabolcs Hubai from comment #10)
> (In reply to Heather Arthur [:harth] from comment #7)
> > We'll need to put some newlines in here after 80 chars.
> 
> Breaks like these, will OK?
> 
> 
> Hmm.... and for savedTabmailSetDocumentTitle? It have a long line too!
> Could you comment this below?
> 
> savedTabmailSetDocumentTitle: 
>   document.getElementById("tabmail") && 
>   typeof(document.getElementById("tabmail").setDocumentTitle) ===
> "undefined" 
>   ? null 
>   : window.document.getElementById("tabmail").setDocumentTitle,
> tabmailSetDocumentTitle: null,
> 
> 
> 

Again the savedTabmailSetDocumentTitle:

...
savedTabmailSetDocumentTitle: 
  document.getElementById("tabmail") && 
    typeof(document.getElementById("tabmail").setDocumentTitle) === "undefined" 
  ? null 
  : window.document.getElementById("tabmail").setDocumentTitle,
tabmailSetDocumentTitle: null,
...


Note the extra ident of typeof().... Will this OK?
(In reply to Szabolcs Hubai from comment #10)
> (In reply to Tony Mechelynck [:tonymec] from comment #6)
> > [...]
> > In reply to comment #4 and #5
> > Requesting a review or a feedback from "the wind" is usually not very
> > effective, but we'll see what we can do. [...]
> 
> Sorry for my english, but I do not really understand what does the
> "requesting something 'from the wind'" mean. Could You explain this?

slang for a review or feedback request without the name of someone who is to do the review or provide the feedback.

For the rest, it looks better to me with the shorter lines. About the finer points (indentation, and whether to break the line before or after the && operator) I'm not really sure.

It's almost 22:00 in Europe at the moment: Jó éjsszakát (and no, "én nem értek magyarul", I just learnt a few useful expressions at the crash course at the Budapest World Congress of Esperanto in 1983).
(In reply to Tony Mechelynck [:tonymec] from comment #9)

> Ah yes, I forgot, there was a merge conflict. Szabolcs (or is it Hubai? I
> know that the Hungarian custom is to write the family name first, but not
> always when writing in English), would you please prepare an unbitrotten
> version of the patch? (i.e. pull mozilla/nightlytt branch "master" into your
> fork, or maybe [your choice] make a new fork, then apply the patch there,
> resolve any merge conflicts, and _then_ submit a new pull request)?

Hm, the patch applied cleanly for me on top of the mozilla/master code.

> suppose (but, Heather, please speak up if you disagree) that if the patch is
> still "recognisably" the same you may carry-over the r+ and set the
> "checkin-needed" on the bug then. Whatever patch you submit should in any
> case apply cleanly on top of the latest commit on the master branch.
> 

Yeah, I gave it an r+ with a few nit-picks, either the author can upload a new patch with the nits fixed, and r+ carries over or the check-in person can fix them before checking in.

> See also https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide but
> remember that if a given source file uses a consistent style, you should
> follow the existing style in the file even if it disobeys the Style Guide.
> (This said, the original NTT developer was Mossop, a Mozilla developer of
> good standing, and I'm confident that he didn't stray away from the "house
> style" unless he had a very good reason.)
> 

Yeah, NTT is a Mozilla project but it's not in any main tree so it can do it's own thing.
(In reply to Szabolcs Hubai from comment #10)

> (In reply to Heather Arthur [:harth] from comment #7)
> > Comment on attachment 586609 [details] [diff] [review]
> > Renew legacy Messenger code v1
> > 
> > Review of attachment 586609 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > Thanks for the patch! Does this require changing the versions numbers of
> > Thunderbird that NTT supports in install.rdf?
> > 
> 
> Since NTT 2.0 the TB compatibility was always more than TB 3.0, 
> therefore I removed the old code while adding the new code.
> If you want to extend the compatibility below 3.0 then somebody have to
> specify how to implement the two customizing method side by side.
> Anyway, I've some ideas. :)
> 
> By the way, the answer is, you don't need to change the compatibility
> numbers for Thunderbird. If somebody test all the NTT features (not just
> this titlebar customizing) with TB3.0. The TabMail introduced in TB3, as
> wrote in the comment 0, so this should work with it.
> Note that I tested this patch with 3.1 and Earlybird (currently: 11).
> 

Great, we won't change the tb compatibility version numbers then.


> Breaks like these, will OK?
> 
> customTabmailSetDocumentTitle: function(aTab)
> {
>   
>   nightlyApp.customTitleModifier = nightlyApp.customTitle.substring(
>       nightlyApp.customTitle.indexOf(nightlyApp.storedTitleMenuSeparator)
>       + nightlyApp.storedTitleMenuSeparator.length
>   );
>   document.documentElement.setAttribute("titlemodifier",
> nightlyApp.customTitleModifier);
>   

That looks fine.

> 
> Hmm.... and for savedTabmailSetDocumentTitle? It have a long line too!
> Could you comment this below?
> 
> savedTabmailSetDocumentTitle: 
>   document.getElementById("tabmail") && 
>   typeof(document.getElementById("tabmail").setDocumentTitle) ===
> "undefined" 
>   ? null 
>   : window.document.getElementById("tabmail").setDocumentTitle,
> tabmailSetDocumentTitle: null,
> 

Looks fine too, just put an extra newline before that tabmailSetDocumentTitle.
(In reply to Szabolcs Hubai from comment #5)
> Created attachment 586618 [details]
> Repacked NTT 3.2.1 from AMO with patch v1
> 
> Repacked version of the 60~70k sized NTT 3.2.1 from AMO.
> Included:
> - patched messenger.js and messengerOverlay.xul
> - the platform directory, recursively! It was left out from the release.
> 
> Please note that somebody need to re-upload the xpi in AMO, because the
> applications miss the binary components!

Sorry for the bugspam but somebody have to re-upload the NTT 3.2.1 xpi with
included platform directory! 
The binary components was left out from the 3.2.1 release, it is only ~67K instead 130K!

From ErrorConsole:
Failed to load native module at path 'F:\FirefoxPortableNightly\Data\profile\extensions\{8620c15f-30dc-4dba-a131-7c5d20cf4a29}\platform\WINNT_x86-msvc\crashme.dll': (80520012) <unknown; can't get error from NSPR>
 ----------
Failed to load native module at path 'F:\FirefoxPortableNightly\Data\profile\extensions\{8620c15f-30dc-4dba-a131-7c5d20cf4a29}\platform\WINNT_x86-msvc\accessory.dll': (80520012) <unknown; can't get error from NSPR>



(In reply to Tony Mechelynck [:tonymec] from comment #12)
> (In reply to Szabolcs Hubai from comment #10)
> > (In reply to Tony Mechelynck [:tonymec] from comment #6)
> > > [...]
> > > In reply to comment #4 and #5
> > > Requesting a review or a feedback from "the wind" is usually not very
> > > effective, but we'll see what we can do. [...]
> > 
> > Sorry for my english, but I do not really understand what does the
> > "requesting something 'from the wind'" mean. Could You explain this?
> 
> slang for a review or feedback request without the name of someone who is to
> do the review or provide the feedback.
> 
Thank You!

I didn't want to assign anybody for those requests, 
because I thought everybody meets for me to be my reviewer.

Of course the next r? would be fayearthur for patch v2.

> For the rest, it looks better to me with the shorter lines. About the finer
> points (indentation, and whether to break the line before or after the &&
> operator) I'm not really sure.
> 
> It's almost 22:00 in Europe at the moment: Jó éjsszakát (and no, "én nem
> értek magyarul", I just learnt a few useful expressions at the crash course
> at the Budapest World Congress of Esperanto in 1983).

:) 
Köszönöm, neked is! :)

Huhh '83? This is My birth year. :O :)



(In reply to Heather Arthur [:harth] from comment #14)
> (In reply to Szabolcs Hubai from comment #10)
> 
> > 
> > Hmm.... and for savedTabmailSetDocumentTitle? It have a long line too!
> > Could you comment this below?
> > 
> > savedTabmailSetDocumentTitle: 
> >   document.getElementById("tabmail") && 
> >   typeof(document.getElementById("tabmail").setDocumentTitle) ===
> > "undefined" 
> >   ? null 
> >   : window.document.getElementById("tabmail").setDocumentTitle,
> > tabmailSetDocumentTitle: null,
> > 
> 
> Looks fine too, just put an extra newline before that
> tabmailSetDocumentTitle.

patch v2 is going to be attached shortly.
Attaching patch v2.

Changes from v1:
- split long savedTabmailSetDocumentTitle
- extra newline after it
- split long customTitleModifier
Attachment #586609 - Attachment is obsolete: true
Attachment #586732 - Flags: review?(fayearthur)
(In reply to Szabolcs Hubai from comment #15)
> (In reply to Szabolcs Hubai from comment #5)
[...]
> > Please note that somebody need to re-upload the xpi in AMO, because the
> > applications miss the binary components!
> 
> Sorry for the bugspam but somebody have to re-upload the NTT 3.2.1 xpi with
> included platform directory! 
> The binary components was left out from the 3.2.1 release, it is only ~67K
> instead 130K!
[...]

Oops... Looks like preparing that extension for upload isn't as opvious as it seems!
(In reply to Tony Mechelynck [:tonymec] from comment #17)
> Oops... Looks like preparing that extension for upload isn't as opvious as
> it seems!

Added new directions to the README, sorry! https://github.com/mozilla/nightlytt
Comment on attachment 586732 [details] [diff] [review]
Renew legacy Messenger code v2 - assigned nits

Review of attachment 586732 [details] [diff] [review]:
-----------------------------------------------------------------

::: chrome/content/messenger.js
@@ +42,5 @@
> +storedTitleModifier: document.documentElement.getAttribute("titlemodifier"),
> +storedTitleMenuSeparator: document.documentElement.getAttribute("titlemenuseparator"),
> +
> +savedTabmailSetDocumentTitle: 
> +  document.getElementById("tabmail") && 

Wait, you've tested this? I'm surprised document.getElementById() would work here as this could be executed before the document loads, I think.
(In reply to Heather Arthur [:harth] from comment #18)
> (In reply to Tony Mechelynck [:tonymec] from comment #17)
> > Oops... Looks like preparing that extension for upload isn't as opvious as
> > it seems!
> 
> Added new directions to the README, sorry!
> https://github.com/mozilla/nightlytt

Sorry myself, I had forgotten about the need to add that when "packaging" the XPI.

Well, I've uploaded a 3.2.1.1 "oilspill release" version (the install.rdf on github is at 3.2.2 so no need to bump it next time we upload from there); "Check for Updates" found it and the next time I restart it will be installed; however I don't use the crashme functionality myself (which may have been one of the reasons I forgot to pack it in).
Yes I tested it and as I said, it worked with 3.1 and 11.

Proposals are welcome!
As you can see this property would contain the reference to the tabmail's object setDocumentTitle function.

Are there any other way to get this reference? For e.g. a getTabMail(), or other getXYZ()?

Of course the second quiestion is: should I drop that (or those?) init line into init() func while defining that/them as null?
(In reply to Tony Mechelynck [:tonymec] from comment #20)
> (In reply to Heather Arthur [:harth] from comment #18)
> > (In reply to Tony Mechelynck [:tonymec] from comment #17)
> > > Oops... Looks like preparing that extension for upload isn't as opvious as
> > > it seems!
> > 
> > Added new directions to the README, sorry!
> > https://github.com/mozilla/nightlytt
> 
> Sorry myself, I had forgotten about the need to add that when "packaging"
> the XPI.
> 
> Well, I've uploaded a 3.2.1.1 "oilspill release" version (the install.rdf on
> github is at 3.2.2 so no need to bump it next time we upload from there);
> "Check for Updates" found it and the next time I restart it will be
> installed; however I don't use the crashme functionality myself (which may
> have been one of the reasons I forgot to pack it in).

NTT 3.2.1.1 is OK now: 
https://crash-stats.mozilla.com/report/index/bp-b2497274-f36a-4f63-bfd0-c35a32120107
(In reply to Szabolcs Hubai from comment #21)
> Yes I tested it and as I said, it worked with 3.1 and 11.
> 
> Proposals are welcome!
> As you can see this property would contain the reference to the tabmail's
> object setDocumentTitle function.
> 
> Are there any other way to get this reference? For e.g. a getTabMail(), or
> other getXYZ()?
> 
> Of course the second quiestion is: should I drop that (or those?) init line
> into init() func while defining that/them as null?

I'm trying this on Thunderbird 9.0 on OS X 10.6 and it's not working, I get the menuitem, but setting a custom title doesn't do anything to the title of Thunderbird. Can you give a screenshot of where this is supposed to be showing?
I can test only with Windows. :(

I am going to make the v3 patch: 
move savedTabmailSetDocumentTitle's init to nightly.init()
Attaching patch v3.

Changes from v2:
- moved savedTabmailSetDocumentTitle's init to nightlyApp.init()


Tested with:
- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a2) Gecko/20120108 Thunderbird/11.0a2 ID:20120108030046
- Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 ID:20111213023509

I hope this will work. If not, I have to fill up nightlyApp with logging statements.
Attachment #586732 - Attachment is obsolete: true
Attachment #586732 - Flags: review?(fayearthur)
Attachment #586833 - Flags: review?(fayearthur)
Attachment #586618 - Attachment is obsolete: true
Attachment #586618 - Flags: feedback?
Comment on attachment 586833 [details] [diff] [review]
Renew legacy Messenger code v3 - document.getElementById

Looks even better. I have no idea why this doesn't work on Mac, but I don't have time to debug it, so I say we check it in for the other users.
Attachment #586833 - Flags: review?(fayearthur) → review+
https://github.com/mozilla/nightlytt/commit/e7caa50f304c26b61c1e79fc7a5995ccae8bb60e
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Verifying with TB 3.1.8 under Linux
Verifying with TB9.0.1 under Linux
Verifying with Earlybird 11.0a2 under Linux
(In reply to Heather Arthur [:harth] from comment #28)
> Comment on attachment 586833 [details] [diff] [review]
> Renew legacy Messenger code v3 - document.getElementById
> 
> Looks even better. I have no idea why this doesn't work on Mac, but I don't
> have time to debug it, so I say we check it in for the other users.

Filed Bug 717192 for this Mac incompatibility.
Blocks: 717192
Blocks: 500006
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: