This issue happens because of the magic number 64 here. It seems it was intended to distinguish which image should be considered as a gallery image. Maybe we have to find a more robust way how to determine which image belongs to the gallery?

Since this is Parsoid HTML, gallery images will be nested in an <ul typeof='mw:Extension/gallery' class="gallery.." ...> .. so, just walk up the tree looking at parents till you hit a UL that has gallery in its list of classes and check if it has the Parsoid-added gallery typeof value.

Change 741691 had a related patch set uploaded (by Vadim Kovalenko; author: Vadim Kovalenko):

[mediawiki/services/mobileapps@master] First image in gallery looks different in Android app

https://gerrit.wikimedia.org/r/741691

I've implemented checking gallery nested elements in order to filter necessary images. I also found that in fact, we have two galleries in mobile apps:

1. Images came from a Template:Gallery ( the case I was working in the scope of this task )
2. Mobile gallery which is available on iOS/Android app when press on the title image. I want to emphasize on it because this image also falls into condition in isGalleryImage(image) method and can be ( or not ) receive classes pcs-widen-image-override pcs-lazy-load-image-loaded. Check main images in this and this arcticles. In the second case (see the shot) main image does not receive pcs-widen-image-override pcs-lazy-load-image-loaded so the text of the next section looks ugly. But this happens only if open mobile html endpoint in the browser. Inspecting this on mobile application doesn't have any side effects.

Shot:

In conclusion, just warn that this patch remakes gallery filtering logic. All images that do not belong to the Template:Gallery will be ignored.

cc: @MSantos

Change 741691 merged by Jgiannelos:

[mediawiki/services/mobileapps@master] First image in gallery looks different in Android app

https://gerrit.wikimedia.org/r/741691