This is consistent with other apps and toolkits (GTK, LibreOffice), and
gives blind people a better experience by providing a consistent
desktop experience, and consistent behavior of the right arrow key
regardless of the first focusable element.
---
layout/xul/nsMenuBarListener.cpp | 2 +-
layout/xul/nsXULPopupManager.cpp | 17 ++++++++++++++++-
toolkit/content/tests/widgets/window_menubar.xul | 14 ++++++++------
3 files changed, 25 insertions(+), 8 deletions(-)
Instead, handle the display: contents case and the ::after case using
FindNextSibling.
The removal of line frames is moved up to not interfere with the insertion point
computation.
Also parentAfterFrame is renamed to nextSibling, which is more relevant to what
it was doing with display: contents.
MozReview-Commit-ID: 1cqclsGQlaw
The only reason not to do that is when there's after content in there. We know
that there isn't really any ::after content, since it would've been handled by
FindNextSibling, so we know we're performing a real append.
MozReview-Commit-ID: ExoPolZy4gG
This removes an unnecessary level of indirection by replacing all
nsStringGlue.h instances with just nsString.h.
--HG--
extra : rebase_source : 340989240af4018f3ebfd92826ae11b0cb46d019
This patch is effectively just resurrecting a function that was previously removed in https://hg.mozilla.org/mozilla-central/rev/173a4f49dfe3#l1.96 .
MozReview-Commit-ID: 4PXSOu4tzzU
--HG--
extra : rebase_source : a8ada7319ea86ccb6178870510fdbb1dac6bd027
If in the future nsDeviceContextSpecWin::BeginDocument was to return
NS_ERROR_FAILURE, then the channel between RemotePrintJobParent and
RemotePrintJobChild will be close at [1]. RemotePrintJobChild keep using ipc
calls after the channel is broken and hits assertions.
PS:
We always hits this assertion by forcing nsDeviceContextSpecWin::BeginDocument
returning NS_ERROR_FAILURE. It's not relative to the change we made in
previous patches.
[1]
https://hg.mozilla.org/mozilla-central/file/b186fddce27f/layout/printing/ipc/RemotePrintJobParent.cpp#l44
MozReview-Commit-ID: 79mZBf301nb
--HG--
extra : rebase_source : 6b84da35fdc96ae8161552fe5d0764b0c2c0f3ee
extra : intermediate-source : 88df2caad42694dd77f2a518ea8d460d6c88b8c6
extra : source : b920088860904c5d28f3dd2f6eda790dc09be003
For the last page, here is the final three messages sent between the content
process, RemotePrintJobChild, and the chrome process, RemotePrintJobParent, for
printing:
1. The content process sends *ProcessPage* to the chrome process via
SendProcessPrint to request the chrome process print the last page.
2. The content process sends *FinalizePrint* to the chrome process via
SendFinalizePrint to notify the chrome that there are no more outstanding
print requests, and that the chrome process can release interal resource
now.
3. The content process receive PageProcessed message from the chrome process.
This calling sequence is fine for sync style PrintTarget (even though the
FinalizePrint message is sent out a bit ealy). Since a sync PrintTarget
completes its print task right after receiving *ProcessPage* message in #1,
sending FinalizePrint before getting PageProcessed response is harmless.
But this message dispatching sequence does cause a problem for async style
PrintTargetEMF. After getting a message sent in #2, PrintTargetEMF release all
resources before getting a EMF conversion response from the PDFium process. So
the last page can not be printed correctly. This patch reorder the #2 and #3
message, that is to send FinalizePrint after the content process received
PageProcessed message of the last page.
MozReview-Commit-ID: 9ZVSrFnuHBU
--HG--
extra : rebase_source : d12161e1c8ac6469fc1ecb9514939bd35979d573
extra : source : 70ce23becf8840408cd72e7f933a167090519c09
Before we introduce PrintTargetEMF, all PrintTargets finish page printing task
before the end of PrintTarget::EndPage(). Unlike others, a page printing
in PrintTargetEMF is done after receiving an async callback from the pdfium
process. So we have both async and sync page printing behavior now. This patch
is trying to make both of them work correctly while priting a content document.
MozReview-Commit-ID: 2PHJToFlvtu
--HG--
extra : rebase_source : 3531dd6a100e9518d8cb9904326250a8318cdad2
extra : source : f61eb00f83acf45511d8448922212dccb12b05aa
This allows logging from the command line without using a webextension.
MozReview-Commit-ID: 6pkDbLXzz3X
--HG--
extra : rebase_source : 92a840d47054e5bef4cd7adf0aadb16f093f7639
The textBreakPoints variable and its related logic are copied from
BuildTextRunForFrames, however, they are not used in
SetupLineBreakerContext at all. Remove the variable allocation and the
unnecessary while loop.
MozReview-Commit-ID: 1AsA6V7aGMh
--HG--
extra : rebase_source : 408b1e4a44e7a7f41be9cafdb72392ed5f518f37
* New USER_CHROME_CSS_LOADED histogram
* Just log a boolean to reflect if the userChrome.css was successfully loaded at profile initialization, in the parent process.
MozReview-Commit-ID: 8ffSNUot43I
--HG--
extra : rebase_source : 11f43e832449952c83cdb104c61c9c33c1aaa123
Mats Palmgren
Colomban Wendling
Narcis Beleuzu
Cosmin Sabou
Phil Ringnalda
Emilio Cobos Álvarez
Eric Rahm
Noemi Erli
Brad Werth
shindli
Neil Deakin
Bogdan Tara
cku
Gerald Squelart
Dorel Luca
Jeremy Chen
Gurzau Raul
Kevin Chen
Sam Foster
Jonathan Watt
Kartikaya Gupta
Ya-Chieh Wu