ad6c81e11152d987f87037d1329f31de16530d77: Bug 1662309 - Update fluent-rs to 0.12. r=kamidphish
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 01 Sep 2020 04:15:51 +0000 - rev 547153
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1662309 - Update fluent-rs to 0.12. r=kamidphish Differential Revision: https://phabricator.services.mozilla.com/D88942
2dde2efbc18dcc245afb25de2732d5b28394bcbb: Bug 1662305 - Remove workaround for shortcomings from kaniko < 1. r=taskgraph-reviewers,aki
Mike Hommey <mh+mozilla@glandium.org> - Tue, 01 Sep 2020 00:35:22 +0000 - rev 547152
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1662305 - Remove workaround for shortcomings from kaniko < 1. r=taskgraph-reviewers,aki Older versions of kaniko didn't handle $PATH correctly in `RUN` commands, and we worked around this by using full paths for the executables. Now that the base image builder is upgraded to kaniko 1, we can remove those workarounds. Differential Revision: https://phabricator.services.mozilla.com/D88932
1a0b21debe92db3bf4db1d04c41da9b3aa8625f1: Bug 1658702 - part 3: Make `AutoDeleteRangesHandler::ComputeRangesToDelete()` quit without modifying the ranges when it shouldn't delete adjacent character(s) in bidi text r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 01 Sep 2020 02:03:23 +0000 - rev 547151
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1658702 - part 3: Make `AutoDeleteRangesHandler::ComputeRangesToDelete()` quit without modifying the ranges when it shouldn't delete adjacent character(s) in bidi text r=m_kato This change is corresponding to the part: https://searchfox.org/mozilla-central/rev/73a14f1b367948faa571ed2fe5d7eb29460787c1/editor/libeditor/HTMLEditSubActionHandler.cpp#3143-3155 When caret is not adjacent the deleting character in bidi text, we may do nothing except putting caret to the character. So, `ComputeRangesToDelete()` shouldn't update the caret position since the caret position will be check by its `Run()` later if `beforeinput` event is not canceled. For avoiding the code duplication, this patch reimplements `EditorBase::SetCaretBidiLevelForDeletion()` as a stack only class and split the check and updating part from correcting the data. Note that by the default pref, the new tests failed since it won't be canceled, and the method still don't compute for deleting a character. Differential Revision: https://phabricator.services.mozilla.com/D88378
1789be3b7d0032e1c8126b58b8597b1adc328915: Bug 1661361 - Show print tab modal while waiting on printer data r=Jamie,pbz
Mark Striemer <mstriemer@mozilla.com> - Tue, 01 Sep 2020 02:26:04 +0000 - rev 547150
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1661361 - Show print tab modal while waiting on printer data r=Jamie,pbz Show the print dialog as soon as the content is ready, rather than after the printer and print settings have been retrieved, then focuses the first form element. Differential Revision: https://phabricator.services.mozilla.com/D88355
605317e5db8a4b51dd41ac3974ddab59e1f3afd7: Bug 1660277 - adjust when we save per-filetype download preferences in the helper app dialog for types handled internally, r=jaws
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Tue, 01 Sep 2020 02:52:20 +0000 - rev 547149
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1660277 - adjust when we save per-filetype download preferences in the helper app dialog for types handled internally, r=jaws Differential Revision: https://phabricator.services.mozilla.com/D88695
0626d2f60030744fc13590e71e0093154b0b50d9: Bug 1658702 - part 2: Make `AutoDeleteRangesHandler::ComputeRangesToDelete()` handle the case deleting empty ancestor(s) r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Tue, 01 Sep 2020 02:02:50 +0000 - rev 547148
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1658702 - part 2: Make `AutoDeleteRangesHandler::ComputeRangesToDelete()` handle the case deleting empty ancestor(s) r=m_kato This patch implements computation of target ranges for this part: https://searchfox.org/mozilla-central/rev/73a14f1b367948faa571ed2fe5d7eb29460787c1/editor/libeditor/HTMLEditSubActionHandler.cpp#3099-3141 This patch adds some utility methods for computing the ranges. Currently, it's not yet standardized, but the other browser engines look for leaf content of another block when blocks are joined (or a block is deleted like this case). Therefore, we follow the behavior basically, but different from the other browsers, we should include invisible white-spaces into the range when they are included. That avoids the invisible white-spaces become visible when web apps do something instead of us. Note that utility methods have the code, but this patch does not use it because in this case, we just delete a empty block ancestor, not join it with previous/next block. Differential Revision: https://phabricator.services.mozilla.com/D88377
9a8d66b99960ecd148e891029d4f183424dbc696: Backed out 20 changesets (bug 1646266) for build bustages at TestBaseProfiler.cpp. CLOSED TREE
Brindusan Cristian <cbrindusan@mozilla.com> - Tue, 01 Sep 2020 05:24:52 +0300 - rev 547147
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Backed out 20 changesets (bug 1646266) for build bustages at TestBaseProfiler.cpp. CLOSED TREE Backed out changeset e2e161965ad3 (bug 1646266) Backed out changeset 5d8691cb0edb (bug 1646266) Backed out changeset 119344e72ed8 (bug 1646266) Backed out changeset da8ae4c7615c (bug 1646266) Backed out changeset d5a7d5139d59 (bug 1646266) Backed out changeset 1eba69baac1f (bug 1646266) Backed out changeset 33da5fe6d185 (bug 1646266) Backed out changeset 60a54b5d7bad (bug 1646266) Backed out changeset 8e65fa28b768 (bug 1646266) Backed out changeset 678a7c5d8a83 (bug 1646266) Backed out changeset 3c1f350a07d5 (bug 1646266) Backed out changeset d091750b1b14 (bug 1646266) Backed out changeset de4d9ab1a6e1 (bug 1646266) Backed out changeset 9eff1a8c358e (bug 1646266) Backed out changeset db3bdff5e4d7 (bug 1646266) Backed out changeset be8fd5f6d335 (bug 1646266) Backed out changeset 220f96d1e3a2 (bug 1646266) Backed out changeset 092c89f164ba (bug 1646266) Backed out changeset ddec14555d7e (bug 1646266) Backed out changeset 8c9ceb8f8dc8 (bug 1646266)
e2e161965ad3b1a25747d8f06c93be57a8989719: Bug 1646266 - Profiler Markers 2.0 tests - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:38:49 +0000 - rev 547146
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - Profiler Markers 2.0 tests - r=gregtatum Differential Revision: https://phabricator.services.mozilla.com/D87260
5d8691cb0edb3dea7f5073e4be3af0112451089e: Bug 1646266 - {,Base}ProfilerMarkerTypes.h - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:38:26 +0000 - rev 547145
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - {,Base}ProfilerMarkerTypes.h - r=gregtatum This patch ports existing ProfilerMarkerPayload types to draft struct definitions that may be used with the new markers API. This is just a starting point, they may be changed later on as needed, see meta-bug 1661394. Differential Revision: https://phabricator.services.mozilla.com/D87259
119344e72ed85a6cdebcb1f04c891a145ebb53f7: Bug 1646266 - {BASE_,}PROFILER_MARKER{,_TEXT} - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:37:53 +0000 - rev 547144
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - {BASE_,}PROFILER_MARKER{,_TEXT} - r=gregtatum This is the main public marker API: - `AddMarkerToBuffer` can be used to store a marker to any buffer. This could be useful to code that wants to store markers outside of the default profiler buffers. - `baseprofiler::AddMarker`/`profiler_add_marker` store a marker in the appropriate profiler buffer. - BASE_PROFILER_MARKER and PROFILER_MARKER do the same, but are also defined (and empty) when MOZ_GECKO_PROFILER is not #defined. All these take a name, marker options, a marker type, and the type's expected arguments if any (as expected by the `StreamJSONMarkerData` function). Extra helpers for the most common types: - BASE_PROFILER_MARKER_UNTYPED and PROFILER_MARKER_UNTYPED store a marker with no data payload. - BASE_PROFILER_MARKER_TEXT and PROFILER_MARKER_TEXT store a text marker. `baseprofiler::markers::Text` is an example of how new marker types can be defined. Differential Revision: https://phabricator.services.mozilla.com/D87257
da8ae4c7615c88efbddc98eafaa7bcd2ba56869c: Bug 1646266 - AddMarkerToBuffer - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:37:32 +0000 - rev 547143
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - AddMarkerToBuffer - r=gregtatum Main marker serialization function, which accepts the same arguments (with implicit conversions) as the marker type's `StreamJSONMarkerData(JSONWriter&, ...)` function, and stores them in a ProfileChunkedBuffer after the marker name and options. Differential Revision: https://phabricator.services.mozilla.com/D87255
d5a7d5139d5992fc80d84252efb324c4d041abe0: Bug 1646266 - Marker Deserialization - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:37:25 +0000 - rev 547142
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - Marker Deserialization - r=gregtatum `DeserializeAfterKindAndStream()` is the main function that extracts all the marker data (past the already-read entry kind), and streams it to JSON using the user-provided `Stream(JSONWriter&, ...)` function in the appropriate marker type definition. It currently requires two external functions to stream the name and the optional backtrace, because these are different between the two profilers. This may change in the future. (Deserialization is implemented before serialization, because the `Deserialize()` function is needed during serialization to get a marker type tag.) Differential Revision: https://phabricator.services.mozilla.com/D87254
1eba69baac1f07fd14b67586b6a476b9151073c5: Bug 1646266 - ProfileBufferEntryKind::Marker - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:37:23 +0000 - rev 547141
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - ProfileBufferEntryKind::Marker - r=gregtatum A new entry kind is needed to serialize the new markers, because they are not encoded the same way. Differential Revision: https://phabricator.services.mozilla.com/D87253
33da5fe6d185e43ff180cbc7e9d085d0ba842fc2: Bug 1646266 - NoPayload default type, with specialized empty helper - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:37:20 +0000 - rev 547140
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - NoPayload default type, with specialized empty helper - r=gregtatum `NoPayload` will be mostly used internally when adding markers without payload data. It has an empty specialization of the MarkerTypeHelper (mainly to catch misuses), and the add-marker code will need to have different compile-time paths to handle it. Differential Revision: https://phabricator.services.mozilla.com/D87252
60a54b5d7bad51159b000d5c3d4c3a0f9fd4eed9: Bug 1646266 - MarkerType::Stream function helpers - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:36:01 +0000 - rev 547139
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - MarkerType::Stream function helpers - r=gregtatum Marker types will be defined with a simple struct that contains (amongst other things) one `StreamJSONMarkerData(JSONWriter&, ...)` function. This patch introduces a type-traits-like helper to examine that function. This will be used to check the arguments given to the upcoming add-marker function, to serialize and deserialize them. Differential Revision: https://phabricator.services.mozilla.com/D87251
8e65fa28b76831d5b561562a2fcd4c47ba79443d: Bug 1646266 - Deserializers and Tags - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:35:43 +0000 - rev 547138
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - Deserializers and Tags - r=gregtatum This is similar to the existing deserializer table in ProfilerMarkerPayload.*: Each type of marker (except the `NoPayload` one) has its corresponding deserializer in a table, and the index is used as a tag in the serialization buffer. Differential Revision: https://phabricator.services.mozilla.com/D87250
678a7c5d8a83a23739179da9c07a4a5cb2569845: Bug 1646266 - MarkerOptions - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:35:21 +0000 - rev 547137
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - MarkerOptions - r=gregtatum A `MarkerOptions` must be constructed from a MarkerCategory, e.g.: `mozilla::baseprofiler::category::OTHER`. This will be required for all markers. `MarkerOptions` also contains defaulted `MarkerThreadId`, `MarkerTiming`, `MarkerStack`, and `MarkerInnerWindowId`. They may be set by calling `WithOptions()` on the MarkerCategory, e.g.: `PROFILER_MARKER<...>("name", OTHER.WithOptions(MarkerThreadId(otherThread), MarkerStack::Capture()), ...);` Differential Revision: https://phabricator.services.mozilla.com/D87249
3c1f350a07d5b5b8be1a2ccb67d7c6f5f9380f52: Bug 1646266 - Marker option: MarkerInnerWindowId - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:34:58 +0000 - rev 547136
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - Marker option: MarkerInnerWindowId - r=gregtatum This option can take an inner window id. Differential Revision: https://phabricator.services.mozilla.com/D87248
d091750b1b14f386673f4f12bcce70ced54c6626: Bug 1646266 - Marker option: MarkerStack - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:34:40 +0000 - rev 547135
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - Marker option: MarkerStack - r=gregtatum This marker option allows three cases: - By default, no stacks are captured. - The caller can request a stack capture, and the add-marker code will take care of it in the most efficient way. - The caller can still provide an existing backtrace, for cases where a marker reports something that happened elsewhere. Differential Revision: https://phabricator.services.mozilla.com/D87247
de4d9ab1a6e1175f2248771c633532bb2ac13d2e: Bug 1646266 - Rework backtrace-capture functions - r=gregtatum
Gerald Squelart <gsquelart@mozilla.com> - Tue, 01 Sep 2020 01:34:17 +0000 - rev 547134
Push 37745 by btara@mozilla.com at Tue, 01 Sep 2020 09:45:42 +0000
Bug 1646266 - Rework backtrace-capture functions - r=gregtatum `profiler_capture_backtrace(ProfileChunkedBuffer&)` renamed to `profiler_capture_backtrace_into(ProfileChunkedBuffer&)` (notice "_into"), which is clearer. New function `profiler_capture_backtrace()` creates a buffer, uses `profiler_capture_backtrace_into()`, and returns a `UniquePtr<ProfileChunkedBuffer>`, which can later be given to `MarkerStack::TakeBacktrace`. `profiler_get_backtrace()` (returning a `UniqueProfilerBacktrace`) now uses `profiler_capture_backtrace()`. This patch reduces most duplicate code between these functions. Differential Revision: https://phabricator.services.mozilla.com/D88280
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip