WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
89715
devicePixelRatio media query layout tests fail when deviceScaleFactor is greater than 1
https://bugs.webkit.org/show_bug.cgi?id=89715
Summary
devicePixelRatio media query layout tests fail when deviceScaleFactor is grea...
Beth Dakin
Reported
2012-06-21 17:13:54 PDT
These two layout tests fail when you run them on a Retina Macbook Pro or any Mac running in HiDPI mode: fast/media/mq-max-pixel-ratio.html fast/media/mq-pixel-ratio.html They behave correctly, but the results that are checked are the results for a 1x display. We could easily change these tests to be display-agnostic, but since there are other differences in HiDPI, it would also be nice to have a new directory like the platform directory for test results that are specific to different deviceScaleFactors.
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2012-06-21 17:14:48 PDT
<
rdar://problem/11723762
>
Dirk Pranke
Comment 2
2012-08-10 11:45:55 PDT
Could these tests could be rewritten to be text-only and use js/dom to query the color being rendered, or is it critical that we actually verify the pixels themselves?
Beth Dakin
Comment 3
2012-08-10 11:51:37 PDT
(In reply to
comment #2
)
> Could these tests could be rewritten to be text-only and use js/dom to query the color being rendered, or is it critical that we actually verify the pixels themselves?
The pixels are not critical in this case, but I think that they only way to truly convert these to text-only tests would be to extend DRT/WTR to be able report back the current device scale factor. The JS/DOM query for devicePixelRatio should not be used because these tests are essentially testing whether or not that very mechanism is accurate, so it needs to be compared against an alternate source of the information. So it would be possibly to avoid separate text expectations in this case if we extended the test harness. But I think it would be simpler to have a platform directory for results since there are still other tests that cannot be translated into text-only tests. For example, all of the canvas tests:
https://bugs.webkit.org/show_bug.cgi?id=89709
Dirk Pranke
Comment 4
2012-08-10 11:56:03 PDT
(In reply to
comment #3
)
> (In reply to
comment #2
) > > Could these tests could be rewritten to be text-only and use js/dom to query the color being rendered, or is it critical that we actually verify the pixels themselves? > > The pixels are not critical in this case, but I think that they only way to truly convert these to text-only tests would be to extend DRT/WTR to be able report back the current device scale factor. The JS/DOM query for devicePixelRatio should not be used because these tests are essentially testing whether or not that very mechanism is accurate, so it needs to be compared against an alternate source of the information. >
Fair enough.
> So it would be possibly to avoid separate text expectations in this case if we extended the test harness. But I think it would be simpler to have a platform directory for results since there are still other tests that cannot be translated into text-only tests. For example, all of the canvas tests:
https://bugs.webkit.org/show_bug.cgi?id=89709
Sure, I have no problem with a platform dir for tests that actually need images (or different text results or whatever), I was just looking for ways to convert some pixel tests to text-only. I was also wondering if these could be reftests, but I'm not seeing an obvious way to do that, either.
Beth Dakin
Comment 5
2012-08-10 12:40:25 PDT
(In reply to
comment #4
)
> Sure, I have no problem with a platform dir for tests that actually need images (or different text results or whatever), I was just looking for ways to convert some pixel tests to text-only. > > I was also wondering if these could be reftests, but I'm not seeing an obvious way to do that, either.
Okay, cool! Yeah, it's true that it's a good goal to have fewer pixel tests anyway. We should definitely consider extending DRT/WRT for this purpose.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug