when we use the view bounds to calculate the composition bounds we fail to make them relative to the reference frame

RESOLVED FIXED in Firefox 30

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: tnikkel, Assigned: tnikkel)

Tracking

29 Branch
mozilla31
x86
macOS
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox29 wontfix, firefox30 fixed, firefox31 fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Created attachment 8392086 [details] [diff] [review]
patch

Bug 935219 added this code. The composition bounds should be relative to the reference frame, but we don't add the offset to make that happen if we use the view bounds.
Attachment #8392086 - Flags: review?(matspal)
Do we need this on 1.3 or 1.4?
Comment on attachment 8392086 [details] [diff] [review]
patch

Seems reasonable to me, but please double-check with someone involved
in bug 935219.
Attachment #8392086 - Flags: review?(matspal) → review+
(Assignee)

Comment 3

5 years ago
Comment on attachment 8392086 [details] [diff] [review]
patch

Ok. That would be kats or botond most likely, kats on pto -> botond.

We don't know if view bounds are the right thing here given bug 983208, but let's at least make the calculation correct. We can delete it later if that's what we find out we should do.
Attachment #8392086 - Flags: review?(botond)
Attachment #8392086 - Flags: review?(botond) → review+
(Assignee)

Comment 4

5 years ago
(In reply to Jason Smith [:jsmith] from comment #1)
> Do we need this on 1.3 or 1.4?

I don't think the situation this applies to comes up in b2g, but is low risk, we should probably just take it.
https://hg.mozilla.org/mozilla-central/rev/3347b7314302
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
(Assignee)

Comment 7

5 years ago
Comment on attachment 8392086 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 935219
User impact if declined: no user visible problems encountered. the calculation is just wrong. bounds need to be relative to reference frame and not themselves. this is a situation that will we hit rarely, perhaps only on metro currently. it's better to keep this code correct and in-sync where it has landed.
Testing completed (on m-c, etc.): just landed m-c
Risk to taking this patch (and alternatives if risky): very low, riskier to keep the current behaviour
String or IDL/UUID changes made by this patch: none
Attachment #8392086 - Flags: approval-mozilla-aurora?
Timothy, do you confirm that it is only for beta? We merged aurora => beta yesterday.
Flags: needinfo?(tnikkel)
(Assignee)

Comment 9

5 years ago
I intend this for aurora (30), ie what just got merged from m-c. Bug 935219 is now on aurora and b2g28. I will get to a b2g28 request after a bit. Does that answer your question?
Flags: needinfo?(tnikkel)
Indeed. So, not 29.  Thanks
Attachment #8392086 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/2602ee663acf
status-b2g-v1.4: --- → fixed
status-b2g-v2.0: --- → fixed
status-firefox29: --- → wontfix
status-firefox30: --- → fixed
status-firefox31: --- → fixed
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.