I'm seeing reftest failures for SVG-as-image on my retina display mbp. For example: https://mxr.mozilla.org/mozilla-central/source/layout/reftests/svg/as-image/border-image-simple-2.html?force=1 Debugging that particular test it seems that when we set up the nsDeviceContext for the SVG-as-image and nsDeviceContext::Init calls nsDeviceContext::SetDPI, we end up on this line with aWidget being null: https://mxr.mozilla.org/mozilla-central/source/gfx/src/nsDeviceContext.cpp?rev=d2730edb36c4&mark=349-350#349 nsDeviceContext::SetDPI nsDeviceContext::Init nsDocumentViewer::CreateDeviceContext nsDocumentViewer::InitInternal nsDocumentViewer::Init mozilla::image::SVGDocumentWrapper::OnStartRequest mozilla::image::VectorImage::OnStartRequest As a result we end up setting mAppUnitsPerDevNotScaledPixel to 60 for the SVG-as-image, while for the document that embeds it we set 30 due to it being displayed on a high resolution screen. This becomes an issue when we come to reflow the SVG-as-image: nsSVGOuterSVGFrame::Reflow nsContainerFrame::ReflowChild nsCanvasFrame::Reflow nsContainerFrame::ReflowChild nsHTMLScrollFrame::ReflowScrolledFrame nsHTMLScrollFrame::ReflowContents nsHTMLScrollFrame::Reflow nsContainerFrame::ReflowChild ViewportFrame::Reflow PresShell::DoReflow PresShell::ResizeReflowIgnoreOverride PresShell::ResizeReflow nsViewManager::DoSetWindowDimensions nsViewManager::SetWindowDimensions nsDocumentViewer::SetBounds mozilla::image::SVGDocumentWrapper::UpdateViewportBounds mozilla::image::VectorImage::CreateDrawableAndShow mozilla::image::VectorImage::Draw The <img> element has CSS px size 100x100, so it end up with a 200x200 device pixel size. This 200x200 dev px size is passed down for aViewportSize in SVGDocumentWrapper::UpdateViewportBounds. nsDocumentViewer::SetBounds then converts this size to app units using the SVG-as-image's AppUnitsPerDevPixel() value, which is 60 instead of 30 as it would be for the embedding document. As a result we end up with an app unit size of 12000x12000 (instead of 6000x6000), that being passed all the way down to the nsSVGOuterSVGFrame::Reflow call. That calls nsSVGSVGElement::SetViewportSize passing a CSS px size of 200x200, which is twice what it should be if its 100x100 CSS px green rect is to fill its area. The green rect then of course fails to fill the entire area of the SVG and as a result border-image-simple-2.html fails because only the top-left quadrant is green instead of the whole thing.

Sounds like VectorImage::CreateDrawableAndShow needs to also set the document's resolution when it sets its size.

It's possible that seth's work in bug 1043560 might help here. (Even if it doesn't help, it's still probably best to wait to address this until bug 1043560 has landed, since the same chunk of code is involved. Hence, setting "depends on" bug 1043560.)

I just posted a minimal test case for showing the wrong media query being triggered. In addition here's a simple work around that so far works for me.

Another demo http://output.jsbin.com/siqufa/ - the <img width="50" height="50"> example changes when moving from a dpr=1 screen to a dpr>=2 screen.

Other people are running into this bug: https://t.co/acHr0nMljm (In reply to Markus Stange [:mstange] from comment #1) > Sounds like VectorImage::CreateDrawableAndShow needs to also set the > document's resolution when it sets its size. This is now VectorImage::CreateSurface. I tried quickly hacking the CSSToLayoutDeviceScale value to 2.0 in nsDeviceContext::SetDPI when there's no widget, but that didn't seem to be sufficient. It did make the media queries pass correctly, but all SVG images painted at half size.

This is one of the issues why SVG-as-an-image can't share computed UA sheet data with other HTML documents, too.