Some followup information on the above bugreport.

Comparing the DOMs in Developer Tools with Canary 54.0.2794.0 on top and Chrome 51.0.2704.103 at the bottom shows a discrepancy. I've highlighted the problematic node: 

http://i.imgur.com/GV5wtVh.png

I counted the divs and they are all closed correctly. For some reason, Canary is placing the main website nodes (page,main and footer) under the modal node, which is display:none by default. Moving these nodes back as children of the wrap div fixes the website:

http://i.imgur.com/XefZSWg.png 

The question is what introduced this bug.

Let's see if the Chromium team can bisect and figure out what broke the parser. 

====================================

Good Build:

54.0.2787.0    Base Position: 403602


Bad Build:

54.0.2794.0    Base Position: 404734

=====================================

Able to repro this issue on Windows 7, MAC (10.11.5) & Ubuntu Trusty (14.04) for the Google Chrome Canary Version - 54.0.2794.0

This is a regression issue broken in M49, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/200b7600c99d19299b9e3990284782e7a7425662..30869b3a11a19398108e1ba1254858f3fcc735ca

Suspecting Commit: 30869b3a11a19398108e1ba1254858f3fcc735ca

Review URL: https://codereview.chromium.org/2101523002

@dominicc: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Ping ping.

Taking a look.

Thanks for filing this bug. I can't reproduce this on Linux at r407100. Did the site change, by any chance?

Unable to repro this issue on Windows 7, MAC (10.11.5) & Ubuntu Trusty (14.04) for Google Chrome Canary Version - 54.0.2803.0 

Screen-recording is attached.

@archon810: Could you please update your Google Chrome Canary - 54.0.2803.0 and let us know your observations.

Thank you.

Deleted: 627379.mp4 416 KB

	627379.mp4 416 KB View Download

I'm the APKMirror dev.

Just tested again on windows using Canary 54.0.2803.0 64bit and I confirm this issue has been fixed.

I did not make any changes to the site that would affect this. Unfortunately Canary updated automatically to the new build for me so I couldn't confirm the old build was still broken.

So it seems that changes were made between builds 2794 and 2803 that affects the rendering of our webpage.

Thanks for your help.

I can confirm 2803 works now. Any idea what the regression was? Otherwise, this is good to close.

Closing this issue as per the comment #9

Would still be interesting to bisect this, rnimmagadda, could you do it?

@dominicc: Would take this up in the next week. This week I'm completely busy with Crash Triaging.

Thank you.

For some unexplained reason this bug still exists on our development website.

To test, load http://dev.apkmirror.com in Chrome stable 52.0.2743.116 m (64-bit) where it displays fine, and compare it to Chrome Canary 54.0.2823.0 (64-bit) where just a gray background is shown.

Surely something must have changed to trigger the incorrect loading of the DOM?

Let me know if you need any more details.

Can this ticket be reopened or should I create a new one?

====================================

Good Build:

54.0.2786.0   Base Position: 403584


Bad Build:

54.0.2815.0   Base Position: 408889

=====================================

Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for the Google Chrome Canary Version - 54.0.2824.0

This is a regression issue broken in M54, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/200b7600c99d19299b9e3990284782e7a7425662..30869b3a11a19398108e1ba1254858f3fcc735ca

Suspecting Commit: 30869b3a11a19398108e1ba1254858f3fcc735ca		

Review URL: https://codereview.chromium.org/2101523002

@dominicc: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

URL Used - http://dev.apkmirror.com

Gah, this snaps a ToT build (at or a bit before r413034). I'll take a look as soon as I can.

SHOULD NEVER BE REACHED
../../third_party/WebKit/Source/core/html/parser/HTMLTreeBuilder.cpp(1391) : voi
d blink::HTMLTreeBuilder::processStartTag(blink::AtomicHTMLToken *)
1   0x7f492d22109e
2   0x7f492d21eb18
3   0x7f492d21dcab
4   0x7f492d1d4e31
5   0x7f492d1d49b4
6   0x7f492d1d2110
7   0x7f492d1d6b9f
8   0x7f492d1d6e66
9   0x7f492d2028cd
10  0x7f492cef8102 blink::PendingScript::streamingFinished()
11  0x7f492c70d1ba blink::ScriptStreamer::notifyFinishedToClient()
12  0x7f492c70c3bd blink::ScriptStreamer::streamingComplete()
13  0x7f492c712372
14  0x7f492c7122c1
15  0x7f492c712262
16  0x7f492c71208c
17  0x7f4937f91ace
18  0x7f4937f91a0e
19  0x7f4937f918a1
20  0x7f49382c116e blink::scheduler::WebTaskRunnerImpl::runTask(std::unique_ptr<
blink::WebTaskRunner::Task, std::default_delete<blink::WebTaskRunner::Task> >)
21  0x7f49382c22f7
22  0x7f49382c2268
23  0x7f49382c2217
24  0x7f49382c1fec
25  0x7f49463832ce
26  0x7f49463b6cdb base::debug::TaskAnnotator::RunTask(char const*, base::Pendin
gTask const&)
27  0x7f4938299df4 blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(
blink::scheduler::internal::WorkQueue*, blink::scheduler::internal::TaskQueueImp
l::Task*)
28  0x7f4938297bc5 blink::scheduler::TaskQueueManager::DoWork(base::TimeTicks, b
ool)
29  0x7f493829eec8
30  0x7f493829ed84
31  0x7f493829ece4
Received signal 11 SEGV_MAPERR 0000fbadbeef
#0 0x7f49463b13de base::debug::StackTrace::StackTrace()
#1 0x7f49463b0f1f base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f49330b6330 <unknown>
#3 0x7f492d2210a5 blink::HTMLTreeBuilder::processStartTag()
#4 0x7f492d21eb18 blink::HTMLTreeBuilder::processToken()
#5 0x7f492d21dcab blink::HTMLTreeBuilder::constructTree()
#6 0x7f492d1d4e31 blink::HTMLDocumentParser::constructTreeFromCompactHTMLToken()
#7 0x7f492d1d49b4 blink::HTMLDocumentParser::processTokenizedChunkFromBackground
Parser()
#8 0x7f492d1d2110 blink::HTMLDocumentParser::pumpPendingSpeculations()

I just checked again, and the latest Canary on Windows loads both dev.apkmirror.com and www.apkmirror.com OK. We did just update to WordPress 4.6 from the previous version, but maybe some Canary updates fixed it?

Thank you for the update. I will close this as "wontfix" meaning it's obsolete, things are working but we don't know for sure what fixed it. We could try bisecting but there's probably more pressing new bugs.