Here is my result at a better resolution with masks (but without patterns) http://i.imgur.com/aBblldB.jpg 

Able to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.6 using chrome latest stable #60.0.3112.90 .

This issue is seen on older version of chrome M35-35.0.1849.0 as well. Hence marking it as untriaged.

Edge also agrees with Chrome and Firefox. The issue is with the maskUnits attribute of the mask.

I tried to remove two maskUnits attributes and the whole girl is visible now. So the creator made SVG incorrectly? I thought we can trust it, because it comes from w3.org .

It probably looked alright in times of creation, but today it looks differently. Maybe the SVG is created in some older SVG specification, and browsers interpret it as a newer specification? What do you think?

I honestly don't know what might have changed over time. SVG implementations have improved greatly over the last few years and my guess is that we now all correctly apply the mask units that were not supported correctly before. I'm not aware of spec changes in this area but then I do not follow closely.

I just thought that somebody could look into the file and say why exactly it looks the way it looks. The same look in three browsers is not a proof that the three browsers must be correct.

Yes, not proof of correctness. But very likely correct for well settled and clearly defined spec like this.

My guess would be that the original generator did not factor in the additional clip that will be formed by 'x', 'y', 'width' and 'height' (looking at the bbox of the <path> within the <mask> and comparing to what 'x', 'y', et.c would resolve to it seems the <path> will be outside/to the right of the additional clip.) I don't know whether Inkscape 0.46 properly supported the additional clip, but maybe it didn't. It's also quite possible that SVGWeb itself did not support the additional clip, and so no one noticed ("two wrongs make a right".)
Also note that the file in question is not really part of the spec or in any way authorative (it's rather just a part of a hosted version of the SVGWeb "polyfill".)
And this is also not a "proof", but doing that would really require minimizing this file to something with less "moving parts" that is easier to assess correctness of. (From one implementor to another: minimizing stuff like this is really an essential skill, so this may a good exercise for you ;-))