The BrowserParent's IPC receive methods for nsIWebProgress events in the
BrowserChild were all doing the same set up to ensure they had the correct
state to process them. This has now been refactored out into a single method.
Differential Revision: https://phabricator.services.mozilla.com/D30730
--HG--
extra : moz-landing-system : lando
Before the WebProgress event handlers started migrating to C++, the parent
process would only receive WebProgress events after the child process had
finished loading the WebProgressChild script. Now that listeners are registered
much earlier (before the BrowserChild has finished setting up its frame
scripts), the BrowserParent would receive WebProgress events that were
heretofore not received unless the BrowserChild was *very* careful about when
it sent the IPC messages.
However, even while being very careful, the OnStateChange event handler would
always fire events for initial about:blank loads that break a lot of unit
tests. Before porting that event, we are now ensuring that the WebProgressChild
has finished loading before the BrowserChild will send IPC messages for these
events to the BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D30252
--HG--
extra : moz-landing-system : lando
PrioritizedEventQueue's template is always EventQueue, so the template
argument is rather useless.
Trying to keep the patch minimal, so CreateMainThread for example is still
a bit weird.
Differential Revision: https://phabricator.services.mozilla.com/D31871
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
DB field name is changed in chrome, so matching that.
Cookie imports fail on newer versions of Chrome
Differential Revision: https://phabricator.services.mozilla.com/D31976
--HG--
extra : moz-landing-system : lando
Previous patch in Bug 1552712 actually didn't set the correct upper bound; it
failed to set the upper bound in cases like:
intersect({[0,10]}, {[0,1], [2,3], [4,5]})
That's clearly the maximum of the lengths of the array, not the minimum.
Differential Revision: https://phabricator.services.mozilla.com/D31946
--HG--
extra : moz-landing-system : lando
I did this instead of just (ab)using the fact that every list item has at least
one counter-increment node because:
* I don't have the bullet frame around by the time we initially compute the
counter increment, which means that I'd need to grow nsBlockFrame / add a
frame property for the list item ordinal, which I think would be unfortunate.
* It feels more consistent with the way regular CSS counters work and with the
way we want ::marker to eventually work.
Differential Revision: https://phabricator.services.mozilla.com/D31990
--HG--
extra : moz-landing-system : lando
When you have a ::after::marker, and you compare one against the other we ended
up with the wrong result because of the pseudotype stuff.
I think this is cleaner now that DoCompareTreePosition handles pseudos properly
(which is really the thing this was working around).
Differential Revision: https://phabricator.services.mozilla.com/D31989
--HG--
extra : moz-landing-system : lando
I'm going to need it to fix the counters code in presence of nested
pseudo-elements.
Differential Revision: https://phabricator.services.mozilla.com/D31988
--HG--
extra : moz-landing-system : lando
I thought I was going to need it but turns out I don't. Still this is worth it I
think.
Differential Revision: https://phabricator.services.mozilla.com/D31987
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
The BrowserParent's IPC receive methods for nsIWebProgress events in the
BrowserChild were all doing the same set up to ensure they had the correct
state to process them. This has now been refactored out into a single method.
Differential Revision: https://phabricator.services.mozilla.com/D30730
--HG--
extra : moz-landing-system : lando
Before the WebProgress event handlers started migrating to C++, the parent
process would only receive WebProgress events after the child process had
finished loading the WebProgressChild script. Now that listeners are registered
much earlier (before the BrowserChild has finished setting up its frame
scripts), the BrowserParent would receive WebProgress events that were
heretofore not received unless the BrowserChild was *very* careful about when
it sent the IPC messages.
However, even while being very careful, the OnStateChange event handler would
always fire events for initial about:blank loads that break a lot of unit
tests. Before porting that event, we are now ensuring that the WebProgressChild
has finished loading before the BrowserChild will send IPC messages for these
events to the BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D30252
--HG--
extra : moz-landing-system : lando
These values were only being used for assertions within IPDL send
methods. They had no positive impact beyond causing crashes when sending
a message over a dead actor.
Differential Revision: https://phabricator.services.mozilla.com/D30235
--HG--
extra : moz-landing-system : lando
Historically we've failed very loudly when receiving a message which was
destined for an actor which had already been destroyed. This had the
effect of requiring manual teardown for most actors, as work would need
to be done to ensure messages weren't sent when the target actor might
be about to tear itself down.
In addition, due to this teardown work being done outside of IPDL, this
work would have to manually be checked in subactors, and involved the
addition of new flags, such as `mIPCOpen`, in order to track whether IPC
had begun to be shut down, and discard messages manually if it had.
It is an ongoing issue that we occasionally miss places where we need to
discard messages, and it is easy to not remember to perform async
destruction when building a new actor, meaning that extra work is
required to correctly discard messages when the actor is being torn
down. Due to the correct decision, almost all of the time, being to
discard the message, this patch takes the approach of transforming the
crash which was previously performed into a message discard.
The hope is that this will reduce the burden on actor implementors, by
allowing the use of `Send__delete__` without first synchronizing with
the remote actor, as well as reduce unintentional crashes.
Differential Revision: https://phabricator.services.mozilla.com/D28892
--HG--
extra : moz-landing-system : lando
Currently, some of the raw JSON logs for mochitest and marionette, et al, include
empty dictionaries, None values and other unremarkable values that are marked
as optional. This fix aims to remove these unnecessary items from being
passed to the raw log.
A method has been added to the log_actions class which removes defaults if they
are marked as optional and the value is included in the default list. This is
called on the kwargs returned by the convert_known method, before being
propagated to the log_raw method for StructuredLogger.
Differential Revision: https://phabricator.services.mozilla.com/D25081
--HG--
extra : moz-landing-system : lando
Add Jitspewing control for tracelogger data. This can be enabled from the profiler or from the JS shell. Usage is as follows:
From browser (ION_SPEW_FILENAME is recommended here so stdout doesn't get clobbered by each process):
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger ION_SPEW_FILENAME=tracelogger ./mach run
2. Enable JSTracer feature in profiler addon
3. Start profiling and ctrl+shift+2 to view profile, and the data will be automatically spewed during profile collection.
From shell:
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger dist/bin/js test.js
2. Data is automatically spewed to stdout when the shell exits, or use ION_SPEW_FILENAME.
There is an optional environment variable JS_TRACELOGGER_SPEW that can be used to emit specific events, for example JS_TRACELOGGER_SPEW="Interpreter,Baseline,GC" will emit only those specific events along with the script and self time of each script.
The structured spewer is also supported with SPEW=tracelogger, and this will emit the tracelogger data for every recorded event.
Differential Revision: https://phabricator.services.mozilla.com/D30033
--HG--
extra : moz-landing-system : lando
Depends on: D31986
### Summary
- [X] Extra margin between paragraphs (about 14px, or whatever 1em is)
- [X] Same amount of padding on all sides - match left spacing. Looks like we need 4px less on the side with the arrow, 2px less on the other side.
- [X] Fully opaque, white-colored background
- [X] Drop shadow should be half as dark (I think this is the MacOS doubled dropshadow issue - it should match the meatball menu's shadow)
- [X] Less space between ending icons and CSS - seems like we can just remove margin-inline-start: 5px
- [X] I think florens may have a better info icon that will be more legible at this small size
!!I just created a new one!!
- [X] Warning icon should be smaller now to match the size of the info icon :)
It was an illusion but I have made it slightly smaller and changed the background position to make it look closer to the same size.
- [X] Seems like it would be helpful if you could select the tooltip text
- Whole tooltip 1px to the right and 2px lower !!I have moved this out to bug 1552146!!
Differential Revision: https://phabricator.services.mozilla.com/D31292
--HG--
extra : moz-landing-system : lando
Changes:
- Applied colors from Victorias mockups.
- Removed `margin-inline-start` from the icon to move it closer to the property value.
Differential Revision: https://phabricator.services.mozilla.com/D31986
--HG--
extra : moz-landing-system : lando
add a site patch to fix PDK video player versions that are broken on Fennec
Differential Revision: https://phabricator.services.mozilla.com/D31122
--HG--
extra : moz-landing-system : lando
Barret Rennie
Olli Pettay
Emilio Cobos Álvarez
Nathan Froyd
Aaron Klotz
Peter Van der Beken
Jason Laster
Brendan Dahl
Jared Wein
Ashley Hauck
Trishul
Chris Pearce
Mike Conley
Cosmin Sabou
Boris Zbarsky
Nika Layzell
Stephen Donner
Steve Fink
Nikki S
Denis Palmeiro
Jeff Walden
Julian Descottes
Michael Ratcliffe
Razvan Maries
Andreea Pavel
Thomas Wisniewski