How can you tell that the page is rendering at 1x? Is it because it's fuzzy?

(I have a Retina display but the interstitial "looks fine" to me. I can't tell if this  is just because my vision isn't good enough to tell, or whether it's a flaky thing to reproduce.)

It's rather strange as definitely links from badssl.com are blurry, also the malware interstitial when visiting http://ianfette.org/ is blurry for me too.

When accessing these interstitials directly from chrome://interstitials they are sharp.

@felt, if you look at the screenshot, the browser chrome is sharp but the text and icons are blurry so assume it's rendering at 1x but it could be something else. I added the chrome://interstitial version side by side for comparison. Current Beta doesn't have this behaviour. 

Deleted: Screen Shot 2016-08-15 at 10.27.29.png 574 KB

	Screen Shot 2016-08-15 at 10.27.29.png 574 KB View Download

Ahhh, you're right, I was testing with chrome://interstitials and that was not looking blurry for me. That is very odd...

I can't bisect. :-/

>
python tools/bisect-builds.py -a mac -g 2824 -b 2827 --use-local-cache -- -no-first-run --user-data-dir=/tmp/bisect expired.badssl.com
Downloading list of known revisions...
Saved revisions 15734-412004 to /Users/lgarron/chromium/src/tools/.bisect-builds-cache.json
Traceback (most recent call last):
  File "tools/bisect-builds.py", line 1172, in <module>
    sys.exit(main())
  File "tools/bisect-builds.py", line 1133, in main
    evaluator, opts.verify_range)
  File "tools/bisect-builds.py", line 740, in Bisect
    raise RuntimeError(msg)
RuntimeError: We don't have enough builds to bisect. revlist: []

Since the interstitials are working in one place and not the other, I've summarized how the two load HTML to see if we can spot the difference. My guess is that the problem comes from how data URIs are treated with Retina displays.

====
Test page [WAI]
https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/interstitials/interstitial_ui.cc?rcl=0&l=122

The test page populates a subclass of URLDataSource, which has a method named StartDataRequest. StartDataRequest comes with a callback that takes the HTML for display as its input.

html = interstitial_delegate.get()->GetHTMLContents();
scoped_refptr<base::RefCountedString> html_bytes = new base::RefCountedString;
html_bytes->data().assign(html.begin(), html.end());
callback.Run(html_bytes.get());

====
Real interstitial [Broken]
https://cs.chromium.org/chromium/src/chrome/browser/ssl/ssl_error_handler.cc?rcl=1471276009&l=335

This relies on a wrapper class telling the InterstitialPage to show itself.

interstitial_page_ = content::InterstitialPage::Create(
      web_contents_, ShouldCreateNewNavigation(), request_url_, this);
interstitial_page_->Show();

Which then leads to the InterstitialPageImpl doing the actual Show operation. The HTML is loaded into a data URL, and then the window is navigated to that data URL.

GURL data_url = GURL("data:text/html;charset=utf-8," +
                       net::EscapePath(delegate_->GetHTMLContents()));
frame_tree_.root()->current_frame_host()->NavigateToInterstitialURL(data_url);

meacer@ awesomely informed me that I've been holding bisect-builds.py wrong.

Here's a real regression range:

https://chromium.googlesource.com/chromium/src/+log/c01760bc132fcc6a8d96b1d567bad36a6614677f..c8e16c4eb9885b21c155d09e7ac04b13eecafe8a

Suspecting https://chromium.googlesource.com/chromium/src/+/8a795f3a48e4e77fabd7b0bb35ee43dac910bb80 ("Cross-process frames should be notified of device scale factor changes.")

wjmaclean@, could you help us fix or triage this bug?

Adding lfg@, who is also looking at some devices scale factor/zoom issues.

I can reproduce this on windows as well.

I'll take a look since James is OOO this week.

I have a fix for this ... I have a bit more testing to do with interstitial types, then I'll write some tests and put a CL up.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/26840c53c281e98b2f33a5e94aa7f04d372eb9c6

commit 26840c53c281e98b2f33a5e94aa7f04d372eb9c6
Author: wjmaclean <wjmaclean@chromium.org>
Date: Wed Aug 24 23:09:29 2016

Fix device scale factor for interstitials.

Implement GetScreenInfo() and UpdateDeviceScaleFactor() for
InterstitialPageImpl so that interstitial pages get the correct device
scale factor both when they're initially created, and also if the window
they're in gets dragged between displays with different device scale
factors.

BUG= 637462 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2265213002
Cr-Commit-Position: refs/heads/master@{#414189}

[modify] https://crrev.com/26840c53c281e98b2f33a5e94aa7f04d372eb9c6/chrome/browser/chrome_site_per_process_browsertest.cc
[modify] https://crrev.com/26840c53c281e98b2f33a5e94aa7f04d372eb9c6/content/browser/frame_host/interstitial_page_impl.cc
[modify] https://crrev.com/26840c53c281e98b2f33a5e94aa7f04d372eb9c6/content/browser/frame_host/interstitial_page_impl.h

Marking this as fixed, but if anyone finds any interstitial pages where it is still broken, please re-open.

 Issue 640648  has been merged into this issue.

This works for me now!

Verified on Chrome 54.0.2840.6

Deleted: Screen Shot 2016-08-31 at 17.48.27.png 169 KB

	Screen Shot 2016-08-31 at 17.48.27.png 169 KB View Download

Security>UX component is deprecated in favor of the Team-Security-UX label