Don't redirect when loading files index page

[CarlSchwan]

Currently we are redirecting from ?dir=/&fileid=2 to ?dir=/. This is an
issue because we then need to load two pages with full file system setup
and authentification instead of one and the assets won't start loading
until the second page is delivered to the user.

Additionally when loading ?dir=/, we then change the url back to
?dir=/&fileid=2 (without reload) so that the next time we load the page
again we do the same thing again.

Depending on the speed of the server and internet connection we can save
100ms to 400ms, improving the user experience.

Questions:

• Why was this introduced in the first place?
• Maybe we can instead fix the js to not rewrite the URL to ?dir=/&fileid=2 and
  then were is no need to kill the redirection as this won't happen each time but
  only when visiting an old URL with &fileid= in the url

Signed-off-by: Carl Schwan carl@carlschwan.eu

[CarlSchwan]

Alternate idea: don't do the redirection when the dir parameter is defined. That probably will kill most of the useless redirection without killing a backward compatible link.

[PVince81]

the "fileid" in URL is authoritative, we need it for the links to work when copy-pasted elsewhere, because the path itself might change

for example test this:

1. create a folder "test"
2. enter the folder
3. copy the URL (which contains fileid)
4. now rename the folder to "test2"
5. open the copied URL in another tab:

thanks to the fileid it can find the actual folder again

now, I'm not sure why we have the original redirect in place from "?dir=xxx&fileid=123" to "?dir=xxx", probably a bug

[PVince81]

I found this: 5e5c5a1

so it seems this controller is the entry point for both the URL format "?dir=xxx&fileid=123" and the private link format "/f/123".

in the case of a private link, the redirect makes sense, but not for when the URL already has the target format

your PR probably breaks links with "/f/$fileid" now, so we should add a condition there

[PVince81]

👍

[PVince81]

/backport to stable23

[PVince81]

/backport to stable22

[MichaIng]

It seems this caused a Drone error. After this was merged, all master branch commits/PR cause the same Drone nodb failures, and the last Drone check on this PR resulted with those errors while other PRs with master base branch and master merges didn't face it:

150 | There were 4 errors:
151 |  
152 | 1) OCA\Files\Tests\Controller\ViewControllerTest::testShowFileRouteWithFolder
153 | Trying to access array offset on value of type null
154 |  
155 | /drone/src/apps/files/lib/Controller/ViewController.php:216
156 | /drone/src/apps/files/tests/Controller/ViewControllerTest.php:461
157 |  
158 | 2) OCA\Files\Tests\Controller\ViewControllerTest::testShowFileRouteWithFile
159 | Trying to access array offset on value of type null
160 |  
161 | /drone/src/apps/files/lib/Controller/ViewController.php:216
162 | /drone/src/apps/files/tests/Controller/ViewControllerTest.php:501
163 |  
164 | 3) OCA\Files\Tests\Controller\ViewControllerTest::testShowFileRouteWithInvalidFileId
165 | Trying to access array offset on value of type null
166 |  
167 | /drone/src/apps/files/lib/Controller/ViewController.php:216
168 | /drone/src/apps/files/tests/Controller/ViewControllerTest.php:521
169 |  
170 | 4) OCA\Files\Tests\Controller\ViewControllerTest::testShowFileRouteWithTrashedFile
171 | Trying to access array offset on value of type null
172 |  
173 | /drone/src/apps/files/lib/Controller/ViewController.php:216
174 | /drone/src/apps/files/tests/Controller/ViewControllerTest.php:578

Okay, given the affected files it is pretty clear that this caused it. @CarlSchwan @PVince81 please review.

[CarlSchwan]

@MichaIng #31294

[PVince81]

potential regression: #32177