WebIF Media Browser Oddity

Black Hole

Black Hole

May contain traces of nut
I've been playing around trying to add a space at the front of a folder name so it gets listed at the top, like " [Flatview]". Thus I have two folders "[Unclassified]" and " [Unclassified]" (and a sweeper rule which puts non-series recordings into the latter).

I'm pleased to say this seems to be working on the ground, but WebIF has trouble with it. The two folders are separately listed, but the leading space does not seem to be displayed (OK, we can put that down to HTML rendering). However, worse: one is full and the other is empty, but WebIF lists them as both having the same number of GiB.

1613759784737.png

1613759832700.png
 
I can (almost) reproduce this using "ABC" and " ABC"
1613762513634.png

The first "ABC" should be 20.4GiB
This is probably related to way the sizes are added to display after the web page is initially displayed without sizes
 
(I notice this thread got moved - I had no idea I hadn't posted in the CF section)

MymsMan said:
This is probably related to way the sizes are added to display after the web page is initially displayed without sizes
Click to expand...
So, you reckon it's the mechanism which goes seeking folder sizes not able to parse the leading space, and therefore finding the same result for both? On second thoughts no - it's finding the contents of the space prefix, not the contents without the space prefix. Why would the space prefix take precedence?
 
It doesn't - it's the first in the sort order of the SUI media list, but it's the last in the WebIF sort order.
 
Do you really need/want two folders with names differing by only leading spaces?
It seems a recipe for confusion for the human user as well as the software.

While the software could be fixed my elderly brain is unlikely to be fixable so I and most other users will stick with easily distinguishable folder names
 
MymsMan said:
It seems a recipe for confusion for the human user as well as the software.
Click to expand...
I wholeheartedly agree. Spaces are delimiters and very widely used as such. Putting them in the middle of things is bad enough. Putting them on the front or the end of things is just insane.
 
MymsMan said:
Do you really need/want two folders with names differing by only leading spaces?
Click to expand...
No, it's only transitional.

MymsMan said:
It seems a recipe for confusion for the human user as well as the software.
Click to expand...
Nonetheless, it reveals a bug. The fact that the bug is easily sidestepped isn't the point.

prpr said:
Putting them on the front or the end of things is just insane.
Click to expand...
See Flatview. I had to jump through hoops to find an input method to do it, and updating my sweeper rules required text editing (rather than sweeper GUI).
 
MymsMan said:
...
This is probably related to way the sizes are added to display after the web page is initially displayed without sizes
Click to expand...
Quite. The file size for directories is lazy-loaded so that the listing isn't held up for multiple invocations of du. The lazy-loader identifies the <span> element to update by its id, which is just the directory name with spaces removed (!). Duplicate IDs make the page non-conforming and so behaviour is undefined: in all the cases above and in my test, only the first item with the id is updated.

To fix this, we'd need a different function that
  • maps the directory to a valid unique HTML id, and
  • can equally be calculated with information available on the client and on the server (so not $dev_$inode).
For instance, we could Base-64 encode the directory name at webif/html/browse/index.jim l.128 and webif/html/browse/script.js l.117. For backward compatibility, a URL-safe variant of Base64 would be needed, as in https://github.com/NeilMadden/tclbase64url (Jim/TCL), https://gist.github.com/jhurliman/1250118 (JS).
 
Black Hole said:
Nonetheless, it reveals a bug. The fact that the bug is easily sidestepped isn't the point.
Click to expand...
Just because it is a bug doesn't mean that it is worth the the considerable effort needed to fix it outlined by @/df
The bug is purely cosmetic and unlikely to be seen again it the next 10 years
I am sure his time would be better spent on problems with a wider impact.
 
I think it is a significant bug that directories with names differing only by whitespace clash. Luckily it's not too hard to fix, at least I hope not. Possibly listings with a lot of directories could be slowed down. The linked PR also improves the name display by making any spaces into non-breaking spaces for HTML.
 
Is this a patch I can apply to test? I see the GIT has "download patch file" and "download diff file" (but the patch file appears to be a diff file plus a header).
 
Last edited:
It doesn't matter the additional header in the patch file is ignored.
Code: 
cd /mod/webif
patch -p2 < /mod/dbg/webif-browse1.patch 
patching file html/browse/index.jim
patching file html/browse/script.js
patching file lib/utils
 
Only problem is that there is an error in the patch file:
Code: 
/mod/webif/lib/utils:104: Error: unmatched "["
in procedure 'entry' called at file "/mod/webif/html/browse/index.jim", line 339
in procedure '::js::escape' called at file "/mod/webif/html/browse/index.jim", line 114
at file "/mod/webif/lib/utils", line 104
 
Yes, something appears awry. The patch seemed to proceed correctly:
Code: 
HDRFOX1# patch -p2 < 5c4d8d087e050b9bd3e5665729931f83ab4229ff.patch                             
patching file html/browse/index.jim                                                             
patching file html/browse/script.js                                                             
patching file lib/utils                                                                         
HDRFOX1#
...but now WebIF >> Browse Media Files doesn't list any folders at all! What to do?

(BTW: it's a shame using Webshell from iOS Safari is such a pain.)
 
It can be reverted using patch -R -p2 < 5c4d8d087e050b9bd3e5665729931f83ab4229ff.patch or opkg install webif --forcereinstall.

I am not sure why it fails, the square brackets appear to be matched.
 
Just in case anybody is reading this:
xyz321 said:
It can be reverted using patch -R -p2 < 5c4d8d087e050b9bd3e5665729931f83ab4229ff.patch or opkg install webif --forcereinstall.
Click to expand...
...should read opkg install webif --force-reinstall
 
You must log in or register to reply here.
Back
Top