========
https://hg.mozilla.org/integration/gaia-central/rev/f4370aed91df
Author: Zac <zcampbell@mozilla.com>
Desc: Merge pull request #17593 from bobsilverberg/plivo_call
Bug 924833 - Re-enable test_receive_call.py
========
https://hg.mozilla.org/integration/gaia-central/rev/8732231c56a3
Author: Bob Silverberg <bob.silverberg@gmail.com>
Desc: Bug 924833 - Re-enable test_receive_call.py
Add a step to check that there are credits available for making a call
Add test to manifest
Address code review comments:
- Fail when Plivo balance is insufficient
- Break out arguments to PlivoUtil __init__
- Use marionette.Wait for waiting
- Add a custom PlivoError exception
- General code cleanup
Address pull request comments:
- move check for balance into make_call in the utility class
- address syntax nits
- add custom message to custom exception
- change syntax for custom exceptions
========
https://hg.mozilla.org/integration/gaia-central/rev/791005d13402
Author: Anthony Ricaud <anthony@ricaud.me>
Desc: Bug 994575 - Add a call should always display the list of contacts
Some code movement for JSHint cleaning
========
https://hg.mozilla.org/integration/gaia-central/rev/db538a2d6aa3
Author: Anthony Ricaud <anthony@ricaud.me>
Desc: Revert "Merge pull request #18421 from Rik/always-contact-home-994575"
The two commits should have been squashed
This reverts commit 1683d067d744af8a7a739d4a96dfee85962b529d, reversing
changes made to 0fd7a3b6de70bd9941b24a3b6c83cbc69f84d628.
Without this patch, when changing the x/y attributes of svg:use, innerSVG and foreignObject, we were relying on the transform changes of the children to trigger the right invalidations. However, changes to those attributes can also change the filter region. And there's a difference between moving children in a fixed filter region and moving the filter region along with the children: In the first case, we wouldn't need to invalidate anything outside the old filter region, because those parts of the children would be clipped away anyway. But when the filter region changes, we need to invalidate both the old and the new filter region. Also, when the filter has primitives without inputs, e.g. flood or turbulence, the filtered frame needs to be invalidate even if it has no children.
This function calculates the offset between "bounding box frame space" and "user space" for SVG frames. For non-SVG frames it returns no offset.
It's crucial that this is consistent with what nsSVGUtils::GetBBox does.
nsFilterInstance has several methods that are called by consumers before the actual painting, e.g. to calculate post filter extents or invalidation regions. Those nsFilterInstance APIs have their input and output values in "bounding box frame space" coordinates, but if the filter units are "objectBoundingBox", then those methods also do calculations involving the result of nsSVGUtils::GetBBox. So a consistent conversion is very important.
There are three spaces that nsSVGIntegrationUtils needs to convert between. I'll call them "frame space", "bounding box frame space" and "user space".
"Bounding box frame space" has its origin at the top left of the union of a frame's border boxes over all continuations.
For SVG frames, "frame space" and "bounding box frame space" are the same because SVG frames don't have multiple continuations.
For non-SVG frames, "bounding box frame space" and "user space" are the same.
However, for SVG frames, "bounding box frame space" and "user space" are different! For example, for a <rect x="100" y="100">, the point 0,0 in frame space is at the rect's top left corner, but the point 0,0 in user space is 100,100 pixels away from the rect's corner.
nsSVGIntegrationUtils::GetOffsetToUserSpace took the non-SVG viewpoint, but it's misleading for SVG frames.
- The condition described in the FIXME comment is already handled by
GetNearestBlockContainer in nsFrame.cpp (helper for
nsIFrame::GetContainingBlock).
