This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
extra : moz-landing-system : lando
As decided during the last TPAC meeting the window rect commands
should not return the window state.
Differential Revision: https://phabricator.services.mozilla.com/D15681
--HG--
extra : moz-landing-system : lando
As decided during the last TPAC meeting the window rect commands
should not return the window state.
Differential Revision: https://phabricator.services.mozilla.com/D15681
--HG--
extra : moz-landing-system : lando
With the use of multiple content processes in Firefox a navigation
command can cause the active framescript to be moved to a different
process. This interrupts the currently executed command, and as such
needs to be executed again after the framescript has been finished
initializing.
Currently flushing the pending commands doesn't take into account
that the framescript can even be moved multiple times to a different
process during a single page navigation. As such all pending commands
are getting removed after the first process move. For navigation
commands this means that no page load listeners are attached for
subsequent process changes, and navigation commands could never
return, and cause a hang of Marionette.
To solve the problem the pending commands need to be flushed each
time the process changes. They will remove themselves from the list
once they have finished processing.
Depends on D10998
Differential Revision: https://phabricator.services.mozilla.com/D10999
--HG--
extra : moz-landing-system : lando
Until now Marionette assumed that the events `TabClose` and `unload`
indicate that a top-level browsing context or chrome window has been
closed. But both events are fired when the browsing context or chrome
window is about to close. As such a race condition can be seen for
slow running builds.
To clearly wait until the top-level browsing context or chrome window
has been closed, the appropriate message manager needs to be observed
for its destroyed state.
MozReview-Commit-ID: DCdaIiULqey
--HG--
extra : rebase_source : f5659c1aa640d5265240bb1c4fe2059fb46d3cac
Until now Marionette assumed that the events `TabClose` and `unload`
indicate that a top-level browsing context or chrome window has been
closed. But both events are fired when the browsing context or chrome
window is about to close. As such a race condition can be seen for
slow running builds.
To clearly wait until the top-level browsing context or chrome window
has been closed, the appropriate message manager needs to be observed
for its destroyed state.
MozReview-Commit-ID: DCdaIiULqey
--HG--
extra : rebase_source : 3f9248ebbdc696ce5e6856ecb167ab144739a52e
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <
Brindusan Cristian
Henrik Skupin
Timothy Guan-tin Chien
Cosmin Sabou
Geoff Lankow
shindli
Andreas Tolfsen
Narcis Beleuzu
Andrew McCreight
Kris Maglione
Dorel Luca
Sebastian Hengst
Wes Kocher