This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
This patch moves us from using an old pref `general.useragent.locale`combined
with `intl.locale.matchOS` for retrieving user requested locale, to use a new
preference `intl.locale.requested` which stores a list of well-formed BCP47
language tags. If set to empty, the OS locales are used. If not set at all,
default locale is used.
We are also adding a piece of code to migrate from old to new system.
MozReview-Commit-ID: 854yQ1kC6Ee
--HG--
extra : rebase_source : c4a7171bc026f857f7878ee83d973ec01b536a84
On Windows 7, there is yy/mm/dd'('ddd')' as short date format of Japanese.
When selecting this, ddd isn't converted to day of the week correctly.
FindInReadable will update start position iterator even if not found. So when
using FindInReadable again, we have to reset start position iterator.
MozReview-Commit-ID: AoS1Txq3Twc
--HG--
extra : rebase_source : 2f02189d0288e833debb2d4ca47efbca632924e5
Add BrowserLocaleManager.refreshLocales, a native function which calls OSPreferences::Refresh, and BrowserLocaleManager.getLocale, which returns the current locale string. Use these in place of observing modification of the intl.locale.os pref.
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: KXJM13VRTB7
--HG--
extra : rebase_source : 3e50b1b3f23248d668d15310554559c39ff792f7
extra : source : 74f5e05877d50a79ec1e5330c227d2ce576a2d90
