========
https://hg.mozilla.org/integration/gaia-central/rev/fbb9373bfe56
Author: GaryChen, PYChen <mmm198219@gmail.com>
Desc: Merge pull request #27766 from joshwalker1026/bug_1126709
Bug 1126709 - Should use the URL() object instead of string concatenation to resolve icon urls for Homescreen application. r=fabrice.
========
https://hg.mozilla.org/integration/gaia-central/rev/c841b03ac943
Author: Josh Cheng <joshwalker.cheng@gmail.com>
Desc: Bug 1126709 - Should use the URL() object instead of string concatenation to resolve icon urls for Homescreen application.
revise_test
========
https://hg.mozilla.org/integration/gaia-central/rev/c74fc72b9c87
Author: John Hu <johu@mozilla.com>
Desc: Revert "Merge pull request #29563 from huchengtw-moz/bug-1154642-context-menu-focus"
This reverts commit 7856cbd44e0c0c2164f3d0896f695645788b0b2f, reversing
changes made to e62169edf3010cce33bac5df48aa8a9c241ce736.
Since bug 960465 patch 14, we've retained finished transitions in order
to handle the issues described in
https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The
code that did this made the assumption that the transition manager is
notified of the full sequence of style changes that happen to an
element. However, when an element becomes part of a display:none
subtree and then later becomes displayed again, the transition manager
is not notified of a style change when it becomes displayed again (when
we do not have the old style context).
This patch introduces code to prune the finished transitions when that
happens.
This really fixes only part of the set of problems described in bug
1158431, which also affect running transitions. However, it's the part
of that set that was a regression from bug 960465, which introduced the
retention of finished transitions, and which makes these issues
substantially easier to hit.
I'd like to fix this part quickly because it's a regression and we
should backport the fix.
Without the patch, I confirmed that the following two tests fail:
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5
With the patch, all the added tests pass.
This isn't spec'ed anywhere (since the whole Web Animations API <-> CSS
interaction isn't spec'ed yet) but it seems that changing animation-play-state
should not restart an idle animation.
If an author calls Cancel() on an animation then that animation should continue
to be idle until they call Play()/Pause() from the API. Cancelling an animation
and hanging on to it is a purely API-only feature and hence it's reasonable that
restoring it from this state is also an API-only feature.
One can imagine use-cases such as polyfilling where script wants to remove any
CSS Animations/Transitions run by the browser and replace them with something
else entirely. In that case, the script can call Cancel() on the animation and
be sure that the animation is going to stay out of the way even if something
else tweaks the animation-play-state.
This patch makes Cancel() call PostUpdate which clobbers certain state in style
so that animated style is correctly flushed when an animation is cancelled.
The main difficulty with this is that we *don't* want to call this when we're
cancelling an animation as a result of a style update or else we'll trigger
needless work. The pattern elsewhere has been to define a *FromStyle() method
for this case (e.g. CSSAnimation::PlayFromStyle, PauseFromStyle). This isn't
ideal because there's always the danger we will forget to call the appropriate
*FromStyle method. It is, however, consistent. Hopefully in bug 1151731 we'll
find a better way of expressing this.
This member is never initialized to anything so it always contains a (0,0)
size, and it shadows the protected mSize member in the base class which is
actually initialized to the correct size.
Even after this patch, it's not OK to AddRef an ImageValue and then call
Release on its base pointer (URLValue) since URLValue refcounting methods
are not virtual, so it would confuse the leak checker, but at least it
wouldn't cause UAF issues since we'd still be looking at the same mRefCnt
member.
The FileImplBase base class has protected mLength and mContentType
members that this class can use. These are currently just masking those
base members.
