Editor changes caret visibility during drag and drop. But when destroying
editor, we don't restore caret state. So we should restore it when destroying
editor.
Co-authored-by: Makoto Kato <m_kato@ga2.so-net.ne.jp>
Based on selected bits of M-C 1461708:
- EventStateManager::CheckForAndDispatchClick() to early-return style
- split EventStateManager::CheckForAndDispatchClick() into:
EventCausesClickEvents, PostHandleMouseUp, DispatchClickEvents
- Move implementation of UIEvent::GetRangeParent() and UIEvent::RangeOffset() to nsLayoutUtils
We have four entry points that deal with the parents of display:none/ display:contents content. These are the functions for setting, changing, getting and removing a style context. Or more specifically:
GetStyleContextInMap called by GetDisplay[None|Contents]StyleFor
SetStyleContextInMap called by RegisterDisplay[None|Contents]StyleFor
ChangeStyleContextInMap called by ChangeRegisteredDisplay[None|Contents]StyleFor
UnregisterDisplay[None|Contents]StyleFor okay, this is actually two functions, but they act as a pair
This change makes all these functions call GetApplicableParent up front and act on and pass around the parent that it returns. This is so that throughout the code we are always handling the parent that will be used as the key in the UndisplayedMap entry. This is necessary so that all the code that sets/gets the 'MayHaveChildrenWithLayoutBoxesDisabled' bit on/from an nsIContent object is using the same object, otherwise everything breaks down.
Partially based on part 2 of https://bugzilla.mozilla.org/show_bug.cgi?id=1367214
This introduces the `ParentForUndisplayedMap` helper method to reduce duplication in terms of getting the parent and asserting parent existence.
Partially based on parts of https://bugzilla.mozilla.org/show_bug.cgi?id=1341083
Changing to vector makes manipulating display list items more risky.
This is to make sure we don't inadvertently end up with duplicates in
the list of display items avoiding double-free scenarios.
The removal of this preference was botched, all other surrounding plumbing changes appear to be working okay. The ability to use prefs to control this stylesheet might be useful in the future, so perhaps this is one of those "if it ain't broke, don't fix it" bugs where leaving well enough alone in the first place would have been the best choice.
With the changes to layout for WebComponents, it is now apparently possible to
pass in null for frame tree items to this function, which would cause a null
deref crash if not checked.
ScrollbarStyles contains values of overflow, (over)scroll-behavior, etc.
The only one which is marginally related to scroll _bars_ is overflow, which can
be used to hide scrollbar (by making an element not scrollable) or enforce the
scrollbar to display.
It makes more sense to be called ScrollStyles as it's mainly concerning behavior
of scrolling, not scrollbars. Also, with the addition of scrollbar width
properties, the current name can be confusing.
Since these are just interpreted comments, there's 0 impact on actual code.
This removes all lines that match /* vim: set(.*)tw=80: */ with S&R -- there are
a few others scattered around which will be removed manually in a second part.
This make MediaQueryList inherit from EventTarget and adds MediaQueryListEvent
as an interface as well as the onchange() method.
This should not affect compatibility with other code; the event object is a
MediaQueryListEvent instance, which is recognized as a MediaListQuery instance.
This is just a clean port of 1322191 and follow-up 1325970. It really seems to add create a new way to access existing code relating to block formatting and floating elements rather than implementing new functionality, and it is mercifully straightforwards.
https://bugzilla.mozilla.org/show_bug.cgi?id=1547792
Aspect Ratio handling simplified by using floating point integers:
- Multiplication of value (or inverse value) to a known side for Scaling
- No unequal equal values such as "4/3" vs "8/6" vs "20/15"
- Truly "Empty" aspect ratios, even if one dimension is not 0
Before issue #146, border-radius on row groups, rows, column groups, or columns don't apply to the background of each cell, yet the border-radius on the cell itself does.
After issue #146, the behaviors changed. In this patch, I tried to revert the behaviors of border-radius on table row groups, rows, column groups, or columns back to what happened before issue #146.
Also: Don't override GetBorderRadii in nsBCTableCellFrame.
Part 1: Remove current table item, as it's never set.
Part 2: Get rid of generic table painting code, and handle each class separately.
Part 4: Hoist outline skipping into col(group) frame code.
Part 5: Skip box-shadow for table column and column groups.
Part 6: Store column and column group backgrounds separately, and then append them before the rest of the table contents.
Part 7: Pass rects in display list coordinates to AppendBackgroundItemsToTop.
Part 8: Create column and column group background display items as part of the cell's BuildDisplayList.
Part 9: Used cached values instead of calling nsDisplayListBuilder::ToReferenceFrame when possible, since it can be expensive when the requested frame isn't the builder's current frame.
Part 10: Make sure we build display items for table parts where only the normal position is visible, since we may need to create background items for ancestors at that position.
Part 11: Create an AutoBuildingDisplayList when we create background items for table columns and column groups, so that we initialize the invalidation state correctly.
Bug 1441796 - Part 1: Optimize the (pseudo)-stacking context conditions
Bug 1441796 - Part 3: Reuse the results in nsIFrame::BuildDisplayListForStackingContext() for ChildrenHavePerspective(), IsTransformed(), and Combines3DTransformWithAncestors()
Bug 1512244 - Part 1: Cleanup DescendIntoChild
