Page MenuHomePhabricator

Proofread scan appearing tiny in wikisource, when creating or editing Page: pages
Closed, ResolvedPublic

Description

Environrment: Ubuntu 16.04, Firefox 59.0.2(64 bit),
Proofread scan appearing tiny (unreadable) in wikisource, when creating a page in page name space. After refreshing, the scan appears in readable size.

This was observed on Chrome browser as well.

proofreadscan showing small.png (612×900 px, 140 KB)

Proofreadscan proper after refresh.png (773×1 px, 263 KB)

Event Timeline

As I see it is a rendering issue, and I am guessing something to do with ResourceLoader where the image is loading under the toolbar with a 15px height

element {

position: absolute;
top: 0px;
left: 0px;
width: 100px;
height: 15px;

}

image.png (50×1 px, 6 KB)

If you simply go backwards up a page, then come forward it redraws fine. So it seems that when it is in a cache it renders properly.

I have observed this effect for few years apearing sometimes randomly. But, indeed, it appears more often recently.

This comment was removed by Ankry.

Change 426637 had a related patch set uploaded (by Tpt; owner: Tpt):
[mediawiki/extensions/ProofreadPage@master] Moves back the loading order of Page: pages editing interface customization to previous state

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

@Aklapper who do we need to nag to get this change reviewed. This is quite an irritation to editing.

Change 426637 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Moves back the loading order of Page: pages editing interface customization to previous state

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

Change 429472 had a related patch set uploaded (by Tpt; owner: Tpt):
[mediawiki/extensions/ProofreadPage@master] Makes sure that the WikiEditor is setup before building Page: pages editing interface

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

Tpt renamed this task from Proofread scan appearing tiny in wikisource, when creating a page to Proofread scan appearing tiny in wikisource, when creating or editing Page: pages.Apr 28 2018, 6:05 PM
Tpt triaged this task as High priority.
Tpt added a subscriber: Vladis13.
Tpt claimed this task.

The change have been deployed and seems to work.

Bodhisattwa subscribed.

Still happening in Bengali Wikisource.

Screenshot from 2018-04-29 19-18-28.png (768×1 px, 222 KB)

Still happening in Russian Wikisource.

See T193328 with detailed explanation.

Still happening in English Wikisource, I believe it is where the image/thumbnail is not cached.

I am wondering whether there was another change at this time that may have occurred in the toolbar area? To me it is just that the first occasion is that the thumbnail is developed after part of the page delivery, yet when you rock and roll the page (back and then forward in the browser) as the image is available (cached) already it just loads fine.

I've been contending with this for some time, but thought it was specific to my computer. As Slowking4 said, this is an issue that "strike[s] at the purpose of this site." It's difficult to do the *single most important* thing on Wikisource. The longer it's a problem, the bigger the negative impact on recruitment and retention of Wikisource editors. If there's a way I can help identify a solution -- more specific info about what causes the problem, or something else -- please let me know.

Change 434305 had a related patch set uploaded (by Tpt; owner: Tpt):
[mediawiki/extensions/ProofreadPage@master] Wait for the page image loaded before initializing zoom

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

Just to let you know that the problem is still there (on English Wikisource). I do agree with Peteforsyth that this is a very important issue, especially for new users, who do not yet know tricks to solve this problem (like: clicking on a new page, then clicking back, and then clicking again). Apart from this, it is time consuming. So if this could be fixed within a short time, that would be great. Greetings, Dick Bos.

Change 434305 merged by jenkins-bot:
[mediawiki/extensions/ProofreadPage@master] Wait for the page image loaded before initializing zoom

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

@Dick_Bos @Peteforsyth @Vladis13 @Bodhisattwa A change that should fix this problem has just been deployed on Wikisource. Could you confirm that this bug is not happening anymore after having purge your browser cache [1]?

[1] https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache

Unfortunately, this continues. On same pages. And on new pages with images that are no in my cache, and I sure on server too, because nobody read these for months.
I did drop cache of my Chromium by ctrl+R, ctrt+F5, clicking on timer in rightup, and by drop cache in browser's History menu.
You can check this by opening the pages for editing at the URL specified above, and on the other pages by the "Next page" tab there.

Working for me on new pages (red link) that I tried at enWS, which was where I had been having the issues.
https://en.wikisource.org/wiki/Index:Surrey_Archaeological_Collections_Volume_1.djvu

@Vladis13 can you give an example of an Index that is problematic?

@Tpt I just cleared my cache and tested a few pages, and so far, it seems to be working! I hesitate to give a definitive answer just now, as the problem has been somewhat sporadic...but I just checked three pages in a row, and previously, it's almost certain at least one out of three would have failed. Thank you for your efforts!

Sure. one, two

Works fine for me at ruWS. I went to the respective index pages, and was able to open 5 pages from first work, and red and redlink pages from second work and had no issues. Randomly picked the other volumes, and no issues on random pages. ¯\_(ツ)_/¯

Strange... For me now, with the issues opens this 2st link, and about half random others. First opens good, then after ~1 sec image reloads to 100px width.

Снимок экрана от 2018-05-24 09-09-18.png (731×1 px, 251 KB)

Strange... For me now, with the issues opens this 2st link, and about half random others. First opens good, then after ~1 sec image reloads to 100px width.

Снимок экрана от 2018-05-24 09-09-18.png (731×1 px, 251 KB)

Agree. For me these same.

Or, another check: please go to link https://ru.wikisource.org/w/index.php?title=Страница:Русский_биографический_словарь._Том_14_(1905).djvu/682&action=edit&redlink=1

  1. For first editing this may be look correctly
  2. If you press F5 for refreshing page, that look is bad again, as above

These same, if you swith to VisualEditor and back - after returning to the Wikitext editor this bad look is present.

Ok, so it seems to not be fully fixed :-(.

This bug is very hard to track because the connection speed and the image thumbnail cache probably affect the appearance or not of the bug (e.g. all the examples you linked were not affected by the bug for me).

I could not promise this problem will be fixed anytime soon, sorry. The current Page: pages UI is a very bad hack on top of WikiEditor and/or the edit toolbar. It is very difficult to make it work properly.

I could not promise this problem will be fixed anytime soon, sorry. The current Page: pages UI is a very bad hack on top of WikiEditor and/or the edit toolbar. It is very difficult to make it work properly.

I'm sorry, but I ask you to try a little more. It should be a very simple mistake if you understand it.

Please see again screenshot:

image.png (638×1 px, 260 KB)

In HTML-code:

  1. width="1024" height="1536"
  2. data-file-width="1891" data-file-height="2836"
  3. style="position: absolute; top: 0px; left: 0px; width: 100px; height: 548px;"

In the third statement calculated width is non-proportional, and this is error. But more than that: in this place to specify the width and height is unnecessary and harmful. If this options is removed from style statement, this look is magicaly improved:

image.png (634×1 px, 449 KB)

If is required some minimal width for scanned images, is may be set some value, as example min-width:600px;, but just not a width and height directly. Please consider this remark seriously.

@Kaganer Thank you for your input.

in this place you do not need to specify the width and height.

This is actually useful for the zooming system I think. The code for it is here: https://github.com/wikimedia/mediawiki-extensions-ProofreadPage/blob/master/modules/jquery/jquery.prpZoom.js

Please to do a pull request if you have a working solution. ProofreadPage never had support from any Wikimedia organization, I am a volunteer just like you who would prefer to spend his evenings to do something else than tracking bugs which do not affect him directly.

I'm sorry again!

I found that when I am turn off all gadgets, the error does not appear.

Seems, the error appears while enabled the gadget mw-input-wpgadgets-Navigation_popups. Also is no the error in anonymity mode that also disabling gadgets.

Thank you for your feedbacks!

Seems, the error appears while enabled the gadget mw-input-wpgadgets-Navigation_popups.

Interesting. I don't see how the popups gadget could interfere with ProofreadPage but there is maybe a relation (change in the code execution order?). I have managed to reproduce the problem on ru.wikisource on Chrome (not on Firefox) with only the default gadget and Navigation_popups activated. I'm going to investigate on it.

@Kaganer Sorry for the not so nice reply earlier. I understand that enduring these bugs is very cumbersome. As a community, Wikisource should probably do something in order to improve the maintenance of its core infrastructure. If you know someone who would be interesting to contribute to ProofreadPage, I would be more than happy to help her/him get on board.

Thank you too! Your help is very useful.
Also before was a problem T176393 that one gadget conflicted with the ProoreadsPage.

On ru-forum proposed a temporary solution, add to personal common.css:

.prp-page-image img { width: 100% !important; height: auto !important; }

On ru-forum proposed a temporary solution, add to personal common.css:

.prp-page-image img { width: 100% !important; height: auto !important; }

Thanks for the temporary solution. Its working for in ta.wikisource

Tpt removed Tpt as the assignee of this task.Oct 27 2020, 3:51 PM
Samwilson subscribed.

Since we've switched to OpenSeadragon for the image viewer, has this issue been resolved?

Since we've switched to OpenSeadragon for the image viewer, has this issue been resolved?

Has the mechanism adding the scan's main div to the interface been changed with this switching?

The problem was probably related to some race in scripts operating on the edit window resulting with either misplacing the scan div or incorrectly setting related CSS and the problem appeared occasionally after some changes in scripts or with specific timing of server responses (eg. due to high load).

However, it seems that nobody has reported this problem again for 3 years, so it probably can be closed regardless whether it is affected by switching to OpenSeadragon, or not.

It should be resolved. Openseadragon loads the images in a completely different way. (We extract the URLs of the image and send it over to Openseadragon which creates it's own canvas and reloads and re-renders the image based on it's canvas height. AFAIR)

Even if we have similar issues, it probably should be reported upstream/filed seperately.

Samwilson claimed this task.

Okay, let's call this fine, and chase any new bugs separately. Thanks!