232691 - replace nsString() nsAutoString() and friends with EmptyC?String()

Status: RESOLVED FIXED

(Core :: General, defect)

Description

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

now that we have EmptyString(), we should replace things like nsString() and
nsAutoString() with EmptyString().

(most of the lxr hits are such hits... I couldn't figure out a query that only
finds what I wanted)

Comment 1

[Boris Zbarsky [:bzbarsky]]

There are also a few NS_LITERAL_C?STRING("") that have snuck into the code again...

Comment 2

[Charles Fenwick]

Attachment: diff -u8

Right now all I know is that this compiles...

Comment 3

[Charles Fenwick]

Attachment: diff-u8

Forgot to save the removal of extraneous items before uploading.  Doh.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 149093 [details] [diff] [review]
diff-u8

>Index: accessible/src/html/nsHTMLFormControlAccessible.cpp
>-        _retval.Assign(NS_LITERAL_STRING(""));  // Default name is blank 
>+        _retval.Assign(EmptyString());  // Default name is blank 

|_retval.Truncate();| is better here.

>Index: accessible/src/html/nsHTMLTableAccessible.cpp

>-  aResult.Assign(NS_LITERAL_STRING(""));  // Default name is blank
>+  aResult.Assign(EmptyString());  // Default name is blank

aResult.Truncate();

> NS_IMETHODIMP nsHTMLTableAccessible::GetName(nsAString& aResult)
> {
>-  aResult.Assign(NS_LITERAL_STRING(""));  // Default name is blank
>+  aResult.Assign(EmptyString());  // Default name is blank

Again.

>Index: accessible/src/xul/nsXULFormControlAccessible.cpp

>-  _retval.Assign(NS_LITERAL_STRING(""));  // Default name is blank 
>+  _retval.Assign(EmptyString());  // Default name is blank 

Here too.

Could you skim over the patch and fix up places that do this to use Truncate?

We should only need EmptyC?String() when passing an empty string to a callee...

Comment 5

[Charles Fenwick]

Attachment: latest and greatest [Checkin: Comment 7]

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 149095 [details] [diff] [review]
latest and greatest
[Checkin: Comment 7]

r+sr=bzbarsky.	For future  reference, you want to request reviews by setting
the flags on the patch accordingly (and filling in the bugmail of the person
whose review you want).

Comment 7

[Boris Zbarsky [:bzbarsky]]

I checked that patch in.  If that's all for the tree, I guess we can resolve
this; otherwise, I'm looking forward to more patches.  ;)

Comment 8

[Charles Fenwick]

Patch for stuff in mozilla/browser and mozilla/toolkit coming up...

Comment 9

[Charles Fenwick]

Attachment: patch for firefox stuff [Checkin: Comment 15]

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 149126 [details] [diff] [review]
patch for firefox stuff
[Checkin: Comment 15]

This needs reviews from firefox people....

Comment 11

[Mike Connor [:mconnor]]

Comment on attachment 149126 [details] [diff] [review]
patch for firefox stuff
[Checkin: Comment 15]

>RCS file: /cvsroot/mozilla/browser/config/mozconfig,v
>retrieving revision 1.8
>diff -u -8 -r1.8 mozconfig
>--- browser/config/mozconfig	7 May 2004 01:09:08 -0000	1.8
>+++ browser/config/mozconfig	23 May 2004 02:40:26 -0000
>@@ -1,14 +1,15 @@
>-
>+mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/firegtk2
>+ac_add_options --enable-default-toolkit=gtk2 

This must have been included by mistake. :)

r=[e-mail] excluding the bit above (no SR needed on this)	

will check this in today, thanks for the patch!

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

(In reply to comment #10)
> This needs reviews from firefox people....

No it didn't, really.  See http://www.mozilla.org/projects/firefox/review.html

  For codebase-wide simple, repetitive changes [...] review from a Firefox Peer
  is not required as long as the patch as a whole has review.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Except that wasn't a codebase-wide change -- it was a firefox-specific change.

Comment 14

[Christopher Aillon (sabbatical, not receiving bugmail)]

I'll note that patch != change.  The change was codebase-wide, but that change
was split into multiple patches, one of which was a firefox-specific patch.  It
has reviews though which is the important thing.

Comment 15

[Mike Connor [:mconnor]]

checked in on aviary and trunk

this is one of those hair-splitting things, if it was part of the original
patch, or even submitted separately but bz gave r+sr to the overall change, I
don't think we'd bat an eye at it.

leaving open in case there's more work on this bug to be done

Comment 16

[J]

I would be willing to work on this, if someone wants to email me a little more info.

jason at mqtclct . com

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

i'll put it here so other people can read it too if interested.

Basically all
nsString()
nsAutoString()
NS_LITERAL_STRING("")

should be replaced by

EmptyString()

(note that this is only without arguments. nsString(...) should not be replaced)

And
nsCString()
nsCAutoString()
NS_LITERAL_CSTRING("")

should be replaced by EmptyCString()

Hopefully there shouldn't be that many left. And if there are none then this bug
should be closed.

Comment 18

[Daniel Kraft]

Attachment: Replaces some nsString()s

This should replace all nsString()-occurences I found by EmptyString().
There are also a couple of new nsString() and ~nsString() calls, but unlike
nsString() EmptyString() is no class, so they can't be replaced (and don't
compile).
Now I'm going to look for the others (nsCString(), nsAutoString(), ...)

Comment 19

[Johnny Stenback (:jst)]

Comment on attachment 169624 [details] [diff] [review]
Replaces some nsString()s

- In xpcom/build/dlldeps.cpp

@@ -128,3 +128,3 @@ void XXXNeverCalled()
     NS_QuickSort(nsnull, 0, 0, nsnull, nsnull);
-    nsString();
+    EmptyString();
     NS_ProxyRelease(nsnull, nsnull, PR_FALSE);

This one is an odd case that we shouldn't change, this empty string constructor
call is here to ensure that the string constructor is properly exported from
this library, so of all these in our codebase, this is the one we want to keep.

r=jst

PS: When requesting reviews, type the email address of the person you want to
review this change (me for instance in this case) in the requestee field, or
it's likely that you won't get a review...

Comment 20

[Daniel Kraft]

Attachment: Replaces all versions of empty strings.

This patch (including the changes of the previous patch) replaces all
occurences of nsC?String(), nsAutoC?String() and NS_LITERAL_C?STRING("") by
EmptyC?String().
Except constructor/destructor calls of the classes nsC?String and
nsAutoC?String.
Of course I can't promise the patch works, but it compiles and this attachment
is submitted using Mozilla with the patch applied...

Comment 21

[Daniel Kraft]

(In reply to comment #19)
> (From update of attachment 169624 [details] [diff] [review] [edit])
> - In xpcom/build/dlldeps.cpp
> 
> @@ -128,3 +128,3 @@ void XXXNeverCalled()
>      NS_QuickSort(nsnull, 0, 0, nsnull, nsnull);
> -    nsString();
> +    EmptyString();
>      NS_ProxyRelease(nsnull, nsnull, PR_FALSE);
> 
> This one is an odd case that we shouldn't change, this empty string constructor
> call is here to ensure that the string constructor is properly exported from
> this library, so of all these in our codebase, this is the one we want to keep.
> 
> r=jst
> 
> PS: When requesting reviews, type the email address of the person you want to
> review this change (me for instance in this case) in the requestee field, or
> it's likely that you won't get a review...
> 

I'm sorry for next patch (includes dlldeps.cpp change), I haven't noticed your
answer before submitting...

Comment 22

[Daniel Kraft]

Attachment: Removes dlldeps.cpp change.

Now the same patch without this dlldeps.cpp-change (of course, it's not much
work to derive this one of the last...). There are still other changes on
dlldeps.cpp, but inside other calls. So I think they can be changed.

Comment 23

[Johnny Stenback (:jst)]

Comment on attachment 169628 [details] [diff] [review]
Removes dlldeps.cpp change.

Looks good to me, r=jst

Comment 24

[Boris Zbarsky [:bzbarsky]]

Actually, is the change to xpcom/tests/StringFactoringTests/profile_main.cpp
correct?  It looks like it's no longer testing nsCString construction....  Then
again, is that file even used?

Comment 25

[Daniel Kraft]

I don't know what exactly xpcom/tests/StringFactoringTests/profile_main.cpp is
for, but if you want to know if the nsString::constructor is visible or works,
it must not be changed. If this is so, I'll undo the changes.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Yeah, I suspect that's what that file is for.

Comment 27

[Daniel Kraft]

Attachment: Removes testfile changes [Checkin: Comment 29]

Comment 28

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 169929 [details] [diff] [review]
Removes testfile changes
[Checkin: Comment 29]

sr=bzbarsky (assuming the r=jst, since the patch didn't really change since
then).

Comment 29

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 169929 [details] [diff] [review]
Removes testfile changes
[Checkin: Comment 29]

I just checked this patch in to trunk for 1.8a6.  If there's nothing left to do
here, the bug should probably be resolved fixed.

Comment 30

[Daniel Kraft]

I don't think there's anything left to do (I replaced all hits except of
con-/destructor calls and calls inside of those test functions). Anyone else
should look at this and resolve the bug.

Comment 31

[Daniel Kraft]

Sorry, I don't know why, but there are still some lxr hits left. I'll look at
them when I find time. 

Comment 32

[Boris Zbarsky [:bzbarsky]]

Note that lxr doesn't update instantaneously, so you may be seeing hits you just
fixed with that patch.

Comment 33

[Boris Zbarsky [:bzbarsky]]

lxr has updated.  This looks fixed.

Comment 34

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

A few more has popped up again.

http://lxr.mozilla.org/mozilla/search?string=NS_LITERAL_STRING(%22%22)
http://lxr.mozilla.org/mozilla/search?string=NS_LITERAL_CSTRING%28%22%22%29
http://lxr.mozilla.org/mozilla/search?string=nsString%28%29   [*]
http://lxr.mozilla.org/mozilla/search?string=nsCString%28%29  [*]

[*] These are mostly false hits, but there are a few real ones too

Comment 35

[Charles Fenwick]

examining... patch to follow...

Comment 36

[Charles Fenwick]

Attachment: latest

Takes care of:

- all NS_LITERAL_STRING("")s
- all nsString()s that appeared to need changing

Does not take care of:

- NS_LITERAL_CSTRING("") in /Java
- nsCString in /Camino

Of course, if there is anything else that should be changed, that I have not
adressed here, note in comments and I'll take care of it ASAP.

Comment 37

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Why not fix it all (i.e. why the "Does not take care of" list?)

Instead of doing |contextStr = NS_LITERAL_STRING("")| do |contextStr.Truncate()|
in libeditor.

Comment 38

[Charles Fenwick]

Attachment: latest improved

After checking out the needed files, I have made the appropriate changes in
them as well.  Therefore, this patch covers everything that I noticed. 

Also covers the change requested in comment 37.

Comment 39

[Mikael Parknert]

Comment on attachment 179867 [details] [diff] [review]
latest improved

>Index: camino/src/preferences/PreferenceManager.mm
>===================================================================
> 
>-  rv = NS_NewNativeLocalFile(nsCString(), PR_TRUE, getter_AddRefs(profDirFile));
>+  rv = NS_NewNativeLocalFile(EmptyString(), PR_TRUE, getter_AddRefs(profDirFile));
>   if (NS_SUCCEEDED(rv)) {
>     // profDirDesc is ASCII so no loss


EmptyString seems like wrong type, should be EmptyCString

Comment 40

[Charles Fenwick]

Attachment: latest improved corrected

Thank you for noticing the error.  My apologies for lack of attention to
detail.

Comment 41

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 179873 [details] [diff] [review]
latest improved corrected

r+sr=bzbarsky; checkins need approval right now, so please remind me to check
this in once the tree reopens, ok?

Comment 42

[Boris Zbarsky [:bzbarsky]]

Given how much longer the tree is likely to be closed, I'd just request approval
and find someone to check this in (I can't do the latter until July...)

Comment 43

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 179873 [details] [diff] [review]
latest improved corrected

Requesting approval.  Nice simple patch and all...

Comment 44

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

When this gets checked in, one of the semicolons here should be removed...

+++ editor/libeditor/html/nsHTMLDataTransfer.cpp	6 Apr 2005 17:02:05 -0000
+    contextStr.Truncate();;

Comment 45

[Boris Zbarsky [:bzbarsky]]

Attachment: Same patch updated to tip [Checkin: Comment 46]

Comment 46

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 189470 [details] [diff] [review]
Same patch updated to tip
[Checkin: Comment 46]

Checked this in for 1.8b4. Can this be re-marked fixed?

Comment 47

[Eli Friedman]

How about the places that do "nsAutoString empty;" for an empty string?  There's
about 15 of those.

Comment 48

[Boris Zbarsky [:bzbarsky]]

Fun.  Post patches!

Comment 49

[Vidar Haarr (not reading bugmail)]

Attachment: nsAutoString -> EmptyString()

In content/xml/document/src/nsXMLDocument.cpp, why does it Truncate the
nsAutoString?

<http://lxr.mozilla.org/mozilla/source/extensions/xforms/nsXFormsXPathParser.cpp#564>

Here, I tried to use EmptyString(), but that gave me some compile error. Silly
as it might sound, I don't know what error. My terminal is not wide enough to
show the errors. Anyone know how to fix that in any way? Some option to gmake
that makes it wrap the errors instead of concatenating them?

Comment 50

[Boris Zbarsky [:bzbarsky]]

> In content/xml/document/src/nsXMLDocument.cpp, why does it Truncate the
> nsAutoString?

I don't think we want to think about it... ;)  There's no good reason for it.

> Here, I tried to use EmptyString(), but that gave me some compile error.

The method it's being passed to should take a const string, but wants a
non-const one.  Just change the method signature?

Comment 51

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 195565 [details] [diff] [review]
nsAutoString -> EmptyString()

>Index: content/xul/content/src/nsXULElement.cpp
>+                if (NS_FAILED(ret = listenerManager->CreateEvent(aPresContext, aEvent, EmptyString(), aDOMEvent))) {

Wrap to 80 chars, please.

>+            if (NS_FAILED(ret = listenerManager->CreateEvent(aPresContext, aEvent, EmptyString(), aDOMEvent)))

Same.

r=bzbarsky with that fixed.

Comment 52

[Vidar Haarr (not reading bugmail)]

Attachment: nsAutoString -> EmptyString() v0.2 [Checkin: Comment 56]

I changed nsXFormsXPathParser.cpp::XPathCompilerException to take a const,
recompiled and ran some XForms W3C tests.

Who should sr?

Comment 53

[Vidar Haarr (not reading bugmail)]

Attachment: nsString() -> EmptyString() (+1 small literal)

And now .. this one has me puzzled:
<http://lxr.mozilla.org/seamonkey/source/mailnews/base/src/nsMsgDBView.cpp#546>.

Comment 54

[Vidar Haarr (not reading bugmail)]

Attachment: nsString() -> EmptyString() (+1 small literal) v0.2

Gah! Forgot a file in the patch. Sorry about the spam.

Comment 55

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

(In reply to comment #53)
> And now .. this one has me puzzled:
> <http://lxr.mozilla.org/seamonkey/source/mailnews/base/src/nsMsgDBView.cpp#546>.

That is a (wrong) attempt to do the same as ToNewUnicode(EmptyString()).

Comment 56

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 195692 [details] [diff] [review]
nsAutoString -> EmptyString() v0.2
[Checkin: Comment 56]

Checked this in.

Comment 57

[Vidar Haarr (not reading bugmail)]

Just so I don't forget it:
<http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSComponent.cpp#1476>

Comment 58

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 195694 [details] [diff] [review]
nsString() -> EmptyString() (+1 small literal) v0.2

Please find a different reviewer; I'm not a peer for the vast majority of this code, and even if I were I wouldn't get to this till at least January.

Comment 59

[Vidar Haarr (not reading bugmail)]

Comment on attachment 195694 [details] [diff] [review]
nsString() -> EmptyString() (+1 small literal) v0.2

I'm frankly not sure who to request from here. Maybe jag for general string use?  If not, maybe brendan for catch-all...

Comment 60

[Tony Mechelynck [:tonymec]]

Hmmm. This "good first bug" is in search of a reviewer since Dec. 2005. Takers, anyone?

Comment 61

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

ugh, indeed. Does the patch still apply? My guess is that it needs to be updated to trunk. Also, right now would not be the right time to land it since we're so close to release.

Comment 62

[Tony Mechelynck [:tonymec]]

Well, the author of the latest patches is "not reading bugmail", so I'm clearing the assignee field so as not to deter new takers. The first task will, I suppose, be to un-bitrot the patch.

Comment 63

[Johnny Stenback (:jst)]

I bet this could be trivially done now with our static analysis tools. No need to do this by hand any more...

Comment 64

[David Mandelin [:dmandelin]]

(In reply to comment #63)
> I bet this could be trivially done now with our static analysis tools. No need
> to do this by hand any more...

It would be interesting to see if someone who is not me or Taras can use Dehydra [1] on this. Automatically generating patches is harder, but a script to find the sites to be changed should not be too hard. After that, someone could make the edits manually if there are few enough, or get in touch with us on creating a patch generator. The checker/patcher could be kept around to take care of any of the old patterns that sneak back in.

The idea would be to use Dehydra to walk over all the function calls (including methods and constructors) in the code, find the call sites for the selected constructors, and print the locations. Dehydra has a standard 'iter' function (see system.js) for iterating over statements. I also have an JS 1.8 iterator function that I find personally easier to use, let me know if anyone wants it.

[1] http://developer.mozilla.org/en/docs/Dehydra_GCC

Comment 65

[Serge Gautherie (:sgautherie)]

<http://mxr.mozilla.org/comm-central/search?string=NS_LITERAL_STRING%28%22%22%29>
{{
NS_LITERAL_STRING("")

Found 7 matching lines in 6 files
}}

Comment 66

[Shriram (irc: Mavericks)]

referring to the above comment, now it says no matching results.
how about derived classes of nsString or nsAutoString?

Comment 67

[Edmund Wong (:ewong)]

Attachment: Changing NS_LITERAL_STRING("") to EmptyString() [Checkin c#88]

- Replacing NS_LITERAL_STRING("") in the mailnews repository.

Comment 68

[Edmund Wong (:ewong)]

Attachment: Replacing NS_LITERAL_STRING("") in the mozilla tree.

- NS_LITERAL_STRING("") -> EmptyString()

Comment 69

[Edmund Wong (:ewong)]

Attachment: Removed declaration of nsAutoString empty. Replaced all 'empty' occurrences with EmptyString()

Comment 70

[Edmund Wong (:ewong)]

Attachment: Patch to remove incident of nsAutoString empty.

Comment 71

[Serge Gautherie (:sgautherie)]

You attached the same patch twice...

See at least:
http://mxr.mozilla.org/comm-central/search?string=String+empty&case=1&find=%5C.cpp

Comment 72

[Edmund Wong (:ewong)]

(In reply to comment #71)
> You attached the same patch twice...
> 
> See at least:
> http://mxr.mozilla.org/comm-central/search?string=String+empty&case=1&find=%5C.cpp

Nix.  Sorry.  will replace it with the right one.

Comment 73

[Edmund Wong (:ewong)]

Attachment: Removed declaration of nsAutoString empty. Replaced all 'empty' occurrences with EmptyString()

Comment 74

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 428889 [details] [diff] [review]
Changing NS_LITERAL_STRING("") to EmptyString() [Checkin c#88]

sr=dbaron, although I don't think this actually needs sr

Comment 75

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 428890 [details] [diff] [review]
Replacing NS_LITERAL_STRING("") in the mozilla tree.

>-    wm->GetMostRecentWindow(NS_LITERAL_STRING("").get(), getter_AddRefs(window));
>+    wm->GetMostRecentWindow(EmptyString(), getter_AddRefs(window));

Maybe leave the .get() unless you're confident it's not needed across all relevant platforms?

sr=dbaron, although I don't think this actually requires sr

Comment 76

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 432300 [details] [diff] [review]
Patch to remove incident of nsAutoString empty.

sr=dbaron, although I don't think this needs superreview

Comment 77

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 432501 [details] [diff] [review]
Removed declaration of nsAutoString empty. Replaced all 'empty' occurrences with EmptyString()

>-            nsAutoString empty;
>-            m_compFields->SetTo(empty);
>-            m_compFields->SetCc(empty);
>-            m_compFields->SetBcc(empty);
>-            m_compFields->SetNewsgroups(empty);
>-            m_compFields->SetFollowupTo(empty);
>+            m_compFields->SetTo(EmptyString());
>+            m_compFields->SetCc(EmptyString());
>+            m_compFields->SetBcc(EmptyString());
>+            m_compFields->SetNewsgroups(EmptyString());
>+            m_compFields->SetFollowupTo(EmptyString());

It might be better to do:
  const nsAString& empty = EmptyString();
and then leave the other lines as-is.  But sr=dbaron either way, although I don't think this requires sr.

Comment 78

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could you add the 'checkin-needed' keyword after revising the patches appropriately?

Comment 79

[Edmund Wong (:ewong)]

Attachment: Defined empty to be EmptyString()

Comment 80

[Edmund Wong (:ewong)]

Attachment: Updating patch as the PluginModule lost its NS_LITERAL_STRING

Comment 81

[Edmund Wong (:ewong)]

Attachment: Updating patch as the PluginModule lost its NS_LITERAL_STRING (v2)

Comment 82

[[e-mail]]

(In reply to comment #75)
>(From update of attachment 428890 [details] [diff] [review])
>>-    wm->GetMostRecentWindow(NS_LITERAL_STRING("").get(), getter_AddRefs(window));
>>+    wm->GetMostRecentWindow(EmptyString(), getter_AddRefs(window));
>Maybe leave the .get() unless you're confident it's not needed across all
>relevant platforms?
FYI GetMostRecentWindow happens to be nsnull-safe anyway.

Comment 83

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/9fbcdeef28c0

Comment 84

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #82)
> (In reply to comment #75)
> >(From update of attachment 428890 [details] [diff] [review] [details])
> >>-    wm->GetMostRecentWindow(NS_LITERAL_STRING("").get(), getter_AddRefs(window));
> >>+    wm->GetMostRecentWindow(EmptyString(), getter_AddRefs(window));
> >Maybe leave the .get() unless you're confident it's not needed across all
> >relevant platforms?
> FYI GetMostRecentWindow happens to be nsnull-safe anyway.

This broke the Maemo mobile builds. Working on a patch to add ".get()" back.

Comment 85

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: fixes Maemo bustage

This patch adds the ".get()" back into the code. I am building locally to verify this is the only part that breaks Maemo (it should be).

Comment 86

[Mark Finkle (:mfinkle) (use needinfo?)]

pushed maemo bustage fix:
http://hg.mozilla.org/mozilla-central/rev/2ea3130f9f7b

Comment 87

[Edmund Wong (:ewong)]

(In reply to comment #86)
> pushed maemo bustage fix:
> http://hg.mozilla.org/mozilla-central/rev/2ea3130f9f7b

My apologies for the bustage.  Will be more careful next time.

Comment 88

[Justin Wood (:Callek)]

Comment on attachment 428889 [details] [diff] [review]
Changing NS_LITERAL_STRING("") to EmptyString() [Checkin c#88]

Pushed as: http://hg.mozilla.org/comm-central/rev/2c9ffd5cdc8a

Comment 89

[Justin Wood (:Callek)]

Comment on attachment 441232 [details] [diff] [review]
Defined empty to be EmptyString()

Pushed as: http://hg.mozilla.org/comm-central/rev/37547c236d72

Comment 90

[Justin Wood (:Callek)]

Comment on attachment 441232 [details] [diff] [review]
Defined empty to be EmptyString()

Backed this out in http://hg.mozilla.org/comm-central/rev/8d290e5c854d

Due to a build error:
/builds/slave/macosx-comm-central-check/build/mailnews/compose/src/nsMsgCompose.cpp:2108: error: invalid initialization of reference of type 'const nsAutoString&' from expression of type 'const nsString'

Comment 91

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: nsHTMLEditRules

Rescued from attachment 195694 [details] [diff] [review]

Comment 92

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Attachment: nsMsgCompose

Rescued from attachment 195694 [details] [diff] [review] as well. This was the only other hunk that still existed.

Comment 93

[David :Bienvenu]

Comment on attachment 552626 [details] [diff] [review]
nsMsgCompose

this doesn't compile - but when protz makes that method scriptable, he could fix this.

Comment 94

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/53bbf9d8a0e5