This warning is saying the operation may be undefined because the value of
->left is not guarenteed to be the same because of undefined order of operations.
Fortunately, this seems like a typo and we actually meant to assign ->bottom
MozReview-Commit-ID: H5G8fnDwIJP
--HG--
extra : rebase_source : cd6a2463a90b6675b12bb8255fe605937771bee8
When we UnregisterAudioSessionNotification in response to an OnSessionDisconnected
message, we unintentionally decrement the refcount before restoring it. This KungFu
grips us for the duration of that operation.
--HG--
extra : rebase_source : 7c7e786064811d040d23741c143d9eef04edb5e0
IMEStateManager has a static instance of InputContext which has some nsString
instances. Then, their members will be released after XPCOM shutdown and
that is detected as unexpected destruction.
Therefore, IMEStateManager should release them by itself at XPCOM shutdown.
Using nsTSubstring::SetCapacity(0) is the simplest way to release only the
string buffers.
MozReview-Commit-ID: LMrQxQF9xPn
--HG--
extra : rebase_source : 7cbaf19b76be8db083c10270d0ee436a1c061ea2
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
Wes Kocher
Eugen Sawin
Tom Ritter
Louis Chang
David Parks
Sebastian Hengst
Stephen A Pohl
Lee Salzman
Markus Stange
Masayuki Nakano
Milan Sreckovic
Ryan Hunt
Mats Palmgren
Jonathan Watt
Nicholas Nethercote
Rob Wu
Chris Peterson
sotaro
Kershaw Chang
Morris Tseng
Brad Werth
James Willcox
cku