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
- Count open file descriptors instead of testing the existence of a file
(because the clipboard is now only reachable through file descriptors,
and not through a file path).
- Use a fixed string instead of a random string. The previous way of
generating a string was non-deterministic, and there was a very small
chance that the generated string was not large enough to trigger the
cache-to-disk-mode.
MozReview-Commit-ID: KOkYOm280Oh
--HG--
extra : rebase_source : 32f1eb0c5beb4f8ebb1728bda481ded21247e0ec
Ensure that only DataStruct::mData + mDataLen, XOR
DataStruct::mCacheFD is used.
(Previously it was possible that all of these members were populated,
which is a waste of memory.)
The effect of this change is visible when SetTransferData is called
multiple times with the same flavor, but with one below the threshold
for storing in-memory, and the other above (=store in a file).
MozReview-Commit-ID: 4UlkKAYsjf
--HG--
extra : rebase_source : fff484301dc87f12685575084993b6bf877f9a9b
The cache file is never directly exposed to consumers of DataStruct,
so it does not make sense to keep the clipboardcache file around
forever.
The only change in this commit is to switch from using a filename to
using a file descriptor. In the destructor, the FD is explicitly closed
(which releases the file data). nsAnonymousTemporaryFile takes care
of removing the file when the destructor is not called (e.g. crashes).
Previously, the clipboard cache was stored in a file called:
TmpD/clipboardcache-N
As of this commit, the clipboard cache is stored at:
TmpD/mozilla-temp-randomN (macOS and Linux)
TmpD/mozilla-temp-files/mozilla-temp-randomN (Windows)
(see xpcom/io/nsAnonymousTemporaryFile.{h,cpp} for more details)
To verify that these files are really gone:
1. Create a document with 500k+ characters, open it in Firefox.
2. Copy its content - this will trigger the clipboard cache.
3. Look for the open file descriptor of the deleted file:
( macOS and Linux: )
lsof +L1 | grep mozilla-temp
4. Copy anything (under the 500k threshold), or quit/kill Firefox.
5. Repeat step 3 and observe that the number of file descriptors
has decreased.
MozReview-Commit-ID: 85GlKQrNUl5
--HG--
extra : rebase_source : b0c6e9540e53ad5e713a9db55f3001d7f53c308a
It has no users in mozilla-central or comm-central. This also lets us remove
nsBaseWidget::GetCursor().
--HG--
extra : rebase_source : 3875ce37c78f82285c4e5dbd8133e9ae3dafa0de
Because nsAString is nicer to work with than char16_t*. The patch relatedly
changes nsIEmbeddingSiteWindow::title and nsIWindowMediator::updateWindowTitle
as well.
--HG--
extra : rebase_source : 0bf332dec3e09af6c39c676f8795b368768a6046
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: 6vgQiU8zN3o
--HG--
extra : rebase_source : 1b536b92ef43f610db057ace6f108620e8d8b4d5
extra : source : 336e21386d5eeb16f1c9893c29377f23b67cc4b0
The problem happened only on themed widget. The problem was triggered by Bug 888870. It just added Windows 8.1 support. When high contrast mode was enabled on Win 10, background color problem happend on themed widgets. There were 2 patterns.
- After hover the menu item, its background color remained highlighted
- After hover the menu item, its background color became black
From it, the problem seemed to be caused by background color drawing of themed widgets. nsNativeThemeWin::DrawWidgetBackground() does the background color drawing. AssumeThemePartAndStateAreTransparent() controls skipping background color drawing of themed widgets. If AssumeThemePartAndStateAreTransparent() was removed, the problem was addressed. From it, how DrawThemeBackground() works seems to be changed on high contrast mode since since Win8.1. To address the problem, the patch remove the skipping on high contrast mode since since Win8.1
In order to let necko postpone the load of favicon, we have to set request context ID to the http channel that is created to load favicon.
This patch starts with passing a request context ID to nsContentUtils::LoadImage and makes other necessary changes to set the request context ID to the channel.
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
--HG--
extra : rebase_source : ae88579f3718884bd4ddd89dfc3885bada3f15a4
dcWidth and dcHieght are used only once, we do not need to define a local
variable for any of them.
MozReview-Commit-ID: Fw5rHqtUPQN
--HG--
extra : rebase_source : 52b5381319fc6626e7f1ec4111dad70482a092cd
Currently, WindowsEMF::InitForDrawing can be used once. With the change in this
patch, we can call WindowsEMF::InitForDrawing and Playback/SaveToFile in pair
as many times as we want.
MozReview-Commit-ID: 4fbY4Q6i9v5
--HG--
extra : rebase_source : 4df3fc7d8663d7f552c96204a16d73261bfc9dd7
Englightenment closes fd 0 on child processes and so pipe() can return a zero fd.
MozReview-Commit-ID: 5d9xQXgwgfv
--HG--
extra : rebase_source : c31aa7ce731ba325993f463b79b446ae67c932dd
CopySurface doesn't respect any existing clips that are applied to the draw
target. It doesn't look like nsNativeThemeGTK uses CopySurface normally, but
when OMTP is enabled the draw target is a DrawTargetCapture which can't
LockBits() which causes us to use CopySurface. This can cause a reftest failure.
MozReview-Commit-ID: 1mYMhQB0r3M
--HG--
extra : rebase_source : d2683dee37ce32049d8daeee786cbb06ba624438
extra : amend_source : 59c48b66f733108636d52047a55889ee0c4e2746
Because UBSan complains about casting -1:
> runtime error: load of value 4294967295, which is not a valid value for type 'nsCursor'
--HG--
extra : rebase_source : 037a96700228ea0d427afa7c25c40490c701cdc4
Wes Kocher
Milan Sreckovic
Stephen A Pohl
Ryan Hunt
Mats Palmgren
Jonathan Watt
Nicholas Nethercote
Rob Wu
Chris Peterson
sotaro
Lee Salzman
Kershaw Chang
Sebastian Hengst
Morris Tseng
Brad Werth
James Willcox
cku
Karl Tomlinson
sebastian@ifyouwantblood.de