The .browserContainer `background` is assigned to a linear-gradient in PBM. This commit updates the RDM css to also set the background instead of the background-color to ensure we override the default value properly.
Differential Revision: https://phabricator.services.mozilla.com/D302729
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Bug 2033191 made sure we only call ownerGlobal on nodes.
As per the discussion in dev-platform, the front-end ~always wants
.documentGlobal. This removes ownerGlobal from the bindings. Following
patch will rename internal GetOwnerGlobal in gecko to GetRelevantGlobal
as per the HTML spec terminology.
Differential Revision: https://phabricator.services.mozilla.com/D297183
Unrelated to this bug, but something I noticed while using RDM: After
exiting RDM, fixed-to-bottom toolbars would sometimes be in the wrong
spot.
Differential Revision: https://phabricator.services.mozilla.com/D295060
This is rather messy, because the approach of "toolbar pushes down browser"
matches the real implementation in Fenix which is also rather messy.
It works well enough to reproduce some formerly mobile-only bugs.
Having this functionality will be helpful during the work on the
"overlap model" (bug 1921331), and the result of that work should let us
simplify this RDM code again.
There's one known bug in this RDM implementation, which is that dragging the
page to scroll down can sometimes scroll the content at twice the desired speed
if the content is also moved by a growing / shrinking toolbar. The real Fenix
implementation does not have this bug. But it's not a big problem.
Differential Revision: https://phabricator.services.mozilla.com/D294785
This also moves the mouse motion detection to the parent, and removes the use of the
contentScrolled message.
The problem with the contentScrolled message is that it doesn't let us know when the mouse button is released.
Rather than adding another message, I think it's simpler to just do mouse tracking in two places.
There's not much value in having the touch simulator (which runs inside the content) do the
scroll tracking.
This patch doesn't remove the code that fires the contentScrolled message.
That might be worth doing in a follow-up, but I'm inclined to leave it for now, in case we want to use
it again in the future.
Differential Revision: https://phabricator.services.mozilla.com/D294783
This gives it a "URL bar" (just a shape with rounded endcaps) and a
"tab count indicator" (just a rounded rect with a 1 in it) just so
that it feels a bit more familiar.
Differential Revision: https://phabricator.services.mozilla.com/D294781
Just feels a bit cleaner and is more consistent with the .dynamic-toolbar-on-top
class which I'll be adding in a future patch.
Differential Revision: https://phabricator.services.mozilla.com/D294779
This makes the dynamic toolbar have the correct size when using page zoom in RDM.
There's one user-visible change that this introduces: The size of the resizer, as well
as the size of the interactive areas of the side resize handles, now depends on the zoom.
Differential Revision: https://phabricator.services.mozilla.com/D294778
Remove the --resizer-offset variable (which really meant "reserved space for side
resize handles") and replace the browser border with an outline, so that at zoom:1
the browser size exactly matches rdm-width x rdm-height. We use negative margins on
the side resize handles to center their interactable location on the respective
side border.
Differential Revision: https://phabricator.services.mozilla.com/D294776
This test is still failing very frequently. Most of the failures seem to be around the long_tap step, so I hope that isolating it to a dedicated file will at least make the intermittent easier to track and investigate.
Maybe the additional isolation will help.
Unable to reproduce consistently locally or on try / verify, so I can't verify my assumptions here.
Differential Revision: https://phabricator.services.mozilla.com/D279823
Adding some checkpoints where we wait in the test instead of asserting immediately, but so far I am not reproducing the issue on try, so not guaranteed to fix it.
Differential Revision: https://phabricator.services.mozilla.com/D279816
The `gBrowser.reloadTab` method was doing a very light reload,
which could preserve iframe overriden locations.
The new method ensures we load the original HTML content back,
this seems to also have an impact on keep-alive which is not longer guaranteed.
Only supports reloading the currently selected tab, to better replicate
real user scenarios. But also to comply to `BrowserCommands.reload`,
which only supports reloading the selected tab.
Also tune the har test, now that requests are really cancelled
and we may try to fetch reponse content for such request.
Differential Revision: https://phabricator.services.mozilla.com/D277433
At the moment, if RDM is opened when a browser/tab is discarded, it will remain in a buggy state, and can no longer be disabled on this tab.
Add a new custom event emitted before the tab is discarded so that RDM can cleanly close the RDM ui.
A test is added to check the new close codepath.
Differential Revision: https://phabricator.services.mozilla.com/D279126
This string should normally only be built at failure time, so I hope it will capture the live list of events captured on the target frame, and might give some insights when the test fails.
Differential Revision: https://phabricator.services.mozilla.com/D278935
Chris H-C