Content served as "application/vnd.wap.xhtml+xml" won’t render

[Bill Filler]

latest from phablet-team/ppa on Nexus 4:

-try to load facebook.com or m.facebook.com
- the url field shows full orange, with crossed-circle icon
- the page never loads and is never displayed

Could be because of UA string?

[Olivier Tilloy (osomon)]

It seems to be due to the UA string indeed. Testing on my desktop, with the default UA string (which gets a "Tablet" token, that’s a separate bug in itself), facebook.com renders correctly. If I hardcode the form factor token to "Mobile", I’m seeing the issue described here.

Here’s some interesting information I’m getting on the console when this happens:

[0307/100830:ERROR:power_save_blocker_ozone.cc(29)] Not implemented reached in content::PowerSaveBlockerImpl::PowerSaveBlockerImpl(content::PowerSaveBlocker::PowerSaveBlockerType, const string&)
[0307/100830:ERROR:power_save_blocker_ozone.cc(32)] Not implemented reached in virtual content::PowerSaveBlockerImpl::~PowerSaveBlockerImpl()

[Olivier Tilloy (osomon)]

I added a DCHECK(false) in PowerSaveBlockerImpl::PowerSaveBlockerImpl(…) (chromium/src/content/browser/power_save_blocker_ozone.cc), and this is the stacktrace I’m getting:

[0307/104455:FATAL:power_save_blocker_ozone.cc(30)] Check failed: false.
 [0x7ffed2f68fea] base::debug::StackTrace::StackTrace()
 [0x7ffed2fd5339] logging::LogMessage::~LogMessage()
 [0x7ffed76c710e] content::PowerSaveBlockerImpl::PowerSaveBlockerImpl()
 [0x7ffed76c6fc4] content::PowerSaveBlocker::Create()
 [0x7ffed73ee28c] content::DownloadFileFactory::CreateFile()
 [0x7ffed740bc08] content::DownloadManagerImpl::StartDownloadWithId()
 [0x7ffed741688e] base::internal::RunnableAdapter<>::Run()
 [0x7ffed7414c23] base::internal::InvokeHelper<>::MakeItSo()
 [0x7ffed7412f66] base::internal::Invoker<>::Run()
 [0x7ffed4ac3b73] base::Callback<>::Run()
 [0x7ffed740acf2] content::DownloadManagerImpl::GetNextId()
 [0x7ffed740b5b6] content::DownloadManagerImpl::StartDownload()
 [0x7ffed741bd4f] content::(anonymous namespace)::StartOnUIThread()
 [0x7ffed741f29e] base::internal::RunnableAdapter<>::Run()
 [0x7ffed741f14f] base::internal::InvokeHelper<>::MakeItSo()
 [0x7ffed741ef7b] base::internal::Invoker<>::Run()
 [0x7ffed2f576ac] base::Callback<>::Run()
 [0x7ffed2ff5b6a] base::MessageLoop::RunTask()
 [0x7ffed2ff5c98] base::MessageLoop::DeferOrRunPendingTask()
 [0x7ffed2ff61e8] base::MessageLoop::DoWork()
 [0x7ffed2e9aa70] oxide::qt::MessagePump::customEvent()
 [0x7ffef6852e8d] QObject::event()
 [0x7ffef682dc4d] QCoreApplication::notify()
 [0x7ffef682d97d] QCoreApplication::notifyInternal()
 [0x7ffef682f147] QCoreApplicationPrivate::sendPostedEvents()
 [0x7ffef6872ab3] <unknown>
 [0x7ffef3d68e04] g_main_context_dispatch
 [0x7ffef3d69048] <unknown>
 [0x7ffef3d690ec] g_main_context_iteration
 [0x7ffef687276c] QEventDispatcherGlib::processEvents()
 [0x7ffef682c84b] QEventLoop::exec()
 [0x7ffef6831fa1] QCoreApplication::exec()
 [0x000000404d31] main
 [0x7ffef4e05ec5] __libc_start_main
 [0x000000403d39] <unknown>

[Olivier Tilloy (osomon)]

The fact that something is starting a download request is suspicious, but regardless, we should be able to override those methods that are not implemented in PowerSaveBlockerImpl, to at the very least do nothing and log a message.

[Olivier Tilloy (osomon)]

Apparently, the request that triggers a download is https://m.facebook.com/?refsrc=http%3A%2F%2Fwww.facebook.com%2F&_rdr

[Olivier Tilloy (osomon)]

I commented out the NOTIMPLEMENTED() calls in chromium/src/content/browser/power_save_blocker_ozone.cc, and the error messages are gone, but the page still doesn’t render, so the problem lies elsewhere.

[Olivier Tilloy (osomon)]

Using wget with the --user-agent switch, I observed that the content served by facebook has mimetype "application/vnd.wap.xhtml+xml", which is probably why chromium kicks in the DownloadResourceHandler.

[Olivier Tilloy (osomon)]

Confirmed by peeking at the list of mime types supported by default (see https://code.google.com/p/chromium/codesearch#chromium/src/net/base/mime_util.cc&l=336).

Not sure whether chromium exposes a mechanism to dynamically add supported mimetypes ("application/vnd.wap.xhtml+xml" should render fine as HTML).

[Olivier Tilloy (osomon)]

Setting the priority to low, as we probably don’t want to be served this kind of content anyway. By using a combination of a sensible default UA string and the UA override mechanism, we will ensure that facebook and other websites serve us the right content.

[Olivier Tilloy (osomon)]

See https://bugzilla.mozilla.org/show_bug.cgi?id=941241 for a detailed analysis of the issue.