re-enable many tests on windows 1803 due to invalid screen resolution whilst testing
Differential Revision: https://phabricator.services.mozilla.com/D19535
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
The TabboxPanel component is the one we use to show the detail
of a given network request. In the console, it's not used until
the user expand a network request, but we do load it at
the same time as the NetworkEventMessage.
We can save some extra work by loading it lazily.
Differential Revision: https://phabricator.services.mozilla.com/D19497
--HG--
extra : moz-landing-system : lando
Some functions or properties are not used anymore in the
codebase, so we can safely delete them.
Other ones are only used in Scratchpad or VariableView,
which we want to get rid off in the next months. We move
those functions directly in Scratchpad/VariableView.
Differential Revision: https://phabricator.services.mozilla.com/D19377
--HG--
extra : moz-landing-system : lando
When preceding mouse event is handled, that may cause changing style of the
target. Therefore, when an eMouseDown or eMouseUp event is handled, handlers
require the latest layout. Currently, nsViewManager::DispatchEvent() tries
to guarantee that with calling nsIPresShell::FlushPendingNotifications()
with FlushType::Layout. However, this just flushes the pending layout in
the PresShell associated with the nsViewManager instance. I.e., if the
target is in a child PresShell, its layout hasn't been flushed.
This patch makes PresShell::EventHandler::HandleEvent() flush pending
notifications at first of handling events using coordinates (only when
eMouseDown or eMouseUp, though). Then, when it realizes that the event
should be handled in a child PresShell, makes it flush its pending
notifications and then, recompute event target with the latest layout if
the layout is actually changed.
Differential Revision: https://phabricator.services.mozilla.com/D13720
--HG--
extra : moz-landing-system : lando
Depends on D17917
As discussed on slack. Let me know if you'd prefer another comment and/or moving this to the message CSS file?
Differential Revision: https://phabricator.services.mozilla.com/D17918
--HG--
extra : moz-landing-system : lando
Had to modify localization to accomodate for the test so I would like an additional review from l10n peers here.
@stas feel free to forward if somebody else should have a look.
Below is a summary of the problem I faced here for localization, without any of the specifics related to aboutdebugging:
```
Localized(
{
id: "my-component-localization-id",
attrs: {
title: true,
value: true,
}
}
SomeSharedComponent{
title: "fallback-title",
value: "fallback-value"
}
);
```
with the ftl:
```
my-component-localization-id =
.title = Localized title
.value = Localized value
```
The `value` prop can take any node, and later on in the development, I need a more complex wrapper (here for tests). It shouldn't impact the localization, but now I can't directly use my localized value:
```
Localized(
{
id: "my-component-localization-id",
attrs: {
title: true,
}
},
SomeSharedComponent{
title: "fallback-title",
value: Localized(
{
id: my-component-localization-value
},
dom.span(
{
className: "some-class-needed-for-tests",
},
"fallback-value"
)
)
}
);
```
with the ftl:
```
my-component-localization-id =
.title = Localized title
my-component-localization-value = Localized value
```
It feels wrong to change the localization here, but the only other solution would be to introduce another Component, just to maintain the same API from the standpoint of the FTL:
```
Localized(
{
id: "my-component-localization-id",
attrs: {
title: true,
value: true,
},
},
SomeNewComponentForFluent{
title: "fallback-title",
value: "fallback-value",
}
);
```
with an additional component
```
class SomeNewComponentForFluent extends PureComponent {
render() {
return SomeSharedComponent{
title: this.props.title,
value: dom.span(
{
className: "some-class-needed-for-tests",
},
this.props.value,
),
};
}
}
```
Did you already face similar situations? Is there a recommendation/pattern we should follow here?
Differential Revision: https://phabricator.services.mozilla.com/D17917
--HG--
extra : moz-landing-system : lando
Yura Zenevich
Thomas Nguyen
Julian Descottes
Joel Maher
Jonathan Kingston
Coroiu Cristina
Nicolas Chevobbe
Oana Pop Rus
Bogdan Tara
Masayuki Nakano
Razvan Caliman
Csoregi Natalia
yulia
Michael Ratcliffe
Mike Conley
Gabriel Luong
shindli
soniasingla
Jason Laster
Florens Verschelde
Jaril
Hubert Boma Manilla
Anthony X
Anshul