In C++ code, `DataTransfer::GetTypes()` are used for checking whether the
`DataTransfer` instance has specific type `DataTransferItem` or not. Therefore,
it does not make sense to retrieve all item types nor compare some types
looking for with the retrieved item types.
This patch adds `DataTransfer::HasType()` and `DataTransfer::HasFile()` for
the current C++ users. They don't take `CallerType` since all C++ users use
`GetTypes()` as `CallertType::System`. And they just call a corresponding
method of `DataTransferItemList`.
Then, `DataTransferItemList` methods compares given type with every items
simply.
Note that this patch moves `DataTransfer::GetTypes()` to `DataTransferItemList`
too because new methods and `GetTypes()` should be maintained at every logic
changes.
The reason why there is no `DataTransfer::HasAnyOfTypes()` method is,
`DataTransfer.h` cannot include `DataTransferItemList.h` due to their
dependency but parameter pack requires inline methods.
Differential Revision: https://phabricator.services.mozilla.com/D60387
When privacy.spoof_english = 2, we should hide the user's
locale in content. So we use en-US default strings for HTML
form elements, such as a Submit button.
We also force GetLocalizedEllipsis() to always return the
ellipsis used by en-US.
Differential Revision: https://phabricator.services.mozilla.com/D35815
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
This simplifies dealing with frames that are pushed/pulled between
continuations during reflow, allows us to avoid the complexity of the
fix to 1459937, and hopefully fixes some of the regressions from bug
1308876.
This disables the changes from bug 1459937 by commenting out a single
line in ReparentFrameInternal in nsBlockFrame.cpp, but all the added
code will be removed in the following patch.
Co-authored-by: Gerald Squelart <gsquelart@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Depends on D36423
Differential Revision: https://phabricator.services.mozilla.com/D36424
Instead of renaming it to mMinISize, I choose mCachedMinISize because
both grid and flex container frames use mCachedMinISize for similar
purpose.
Differential Revision: https://phabricator.services.mozilla.com/D29747
This patch is generated by running the following script under layout/,
and then manually delete the FIXME comment in LayoutConstants.h
#!/bin/bash
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename NS_INTRINSIC_WIDTH_UNKNOWN NS_INTRINSIC_ISIZE_UNKNOWN
Differential Revision: https://phabricator.services.mozilla.com/D29746
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
This is closer to what other UAs do, it's simpler, and fixes the bug.
It looks like the complexity of multiple buttons or what not is related to
bug 1188880, which is WONTFIX. We no longer have multiple buttons in the same
file input, so this is better IMO.
Differential Revision: https://phabricator.services.mozilla.com/D26825
There's only one button in a file input. This used to be an
input[type="button"].
There's no point in using more specific rules or such, the regular UA rules just
work, and content can't style this button so it can't be overriden.
This should be an idempotent patch.
Differential Revision: https://phabricator.services.mozilla.com/D26753
nsUnicodeProperties.h includes into ICU, which has implicit int
truncation, so quarantine this include out of problematic headers.
Depends on D25498
Differential Revision: https://phabricator.services.mozilla.com/D25499
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Currently, a lot of code dispatch "input" event and some of them dispatch
"input" event with wrong interface and/or values. Therefore this patch
creates nsContentUtils::DispatchInputEvent() to make all of them dispatch
correct event.
Unfortunately, due to bug 1506439, we cannot set pointer to refcountable
classes of MOZ_CAN_RUN_SCRIPT method to nullptr. Therefore, this patch
creates temporary RefPtr<TextEditor> a lot even though it makes damage to
the performance if it's in a hot path.
This patch makes eEditorInput event dispatched with
InternalEditorInputEvent when "input" event should be dispatched with
dom::InputEvent. However, this patch uses WidgetEvent whose message is
eUnidentifiedEvent and setting WidgetEvent::mSpecifiedEventType to
nsGkAtoms::oninput when "input" event should be dispatched with
dom::Event because we need to keep that eEditorInput and
InternalEditorInputEvent are mapped each other.
Differential Revision: https://phabricator.services.mozilla.com/D12244
The label of the button comes from the UI; it's direction should be independent
of the web content directionality. As there is no access to :-moz-locale-dir()
selectors in HTML, we'll have to rely on auto-direction here.
The alternative (or, addition to the fix here) would be adding the value of
the dir attribute to HtmlForm.properties, allowing the localizers to set
the directionality explicitly. I however don't know if that's necessary.
MozReview-Commit-ID: 5NXeLtxLXVH
I left some IgnoredErrorResults for now where people warn on failure. We could
consider adding a WarnOnError() thing or something.
MozReview-Commit-ID: L5ttZ9CGKg0
