Report Viewer broken

[sebinside]

Unfortunately, the current version of the comparison view of the (deployed) version of the report viewer is broken. This has already been discussed in the last PR #535 and now has independently been found by @tsaglam. An example zip is attached. The error looks similar with something broken in the store.ts file:

TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))
    at Function.from (<anonymous>)
    at Object.<anonymous> (store.ts:32:26)
    at Pt.getComparison (ComparisonFactory.ts:5:40)
    at setup (index.js:60:30)
    ...

@nestabentum Please try to look at this as soon as possible, as it affects the publicly deployed report viewer.

[nestabentum]

I will look into it as soon as possible. I took a quick look at the files you attached - the file Test.java in Submissions/Timur seems to be corrupted. It is has a size of 0kb and opening displays no contents. Is this also the case for the local version of your files or was it corrupted during the upload @tsaglam?

[tsaglam]

Is this also the case for the local version of your files or was it corrupted during the upload @tsaglam?

Ah, sorry. Yes, there is an empty file in there, these files are old demo files, and JPlag should be able to handle empty files. I should have mentioned it, though. However, the issue also persists without the empty file (on all combinations of Windows 10 and macOS Monterey with Firefox and Chrome):

ReportViewerProblem.zip

[nestabentum]

Of course, I will add compatibility with empty files. However, I zipped up the results folder dropped it into the viewer and the comparison view works perfectly fine (except for the missing match indication):

I did all of this on macOS Monterey, with the built-in compression and tested the viewer in Chrome, Firefox and Safari. What program did you use for compression and on what OS did you execute the compression? @tsaglam

[tsaglam]

(Oops, I edited ur comment by accident!)

I did all of this on macOS Monterey, with the built-in compression and tested the viewer in Chrome, Firefox and Safari. What program did you use for compression and on what OS did you execute the compression?

I used the built-in compression on macOS and 7zip on Windows. This is really odd!

HW/SW details

Browsers:

• Firefox 103.0.1 (64-Bit)
• Chrome 103.0.5060.134 (x86_64)

Maven used to built the jar:

Apache Maven 3.8.3 (ff8e977a158738155dc465c6a97ffaf31982d739)
Maven home: /usr/local/Cellar/maven/3.8.3/libexec
Java version: 17.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "12.0.1", arch: "x86_64", family: "mac"

Do you have access to any other system by chance?

[tsaglam]

I just tested it with another MacBook, which is never an ARM one. There it works, but only after rezipping the files.
This means if I zip the results on the older Intel-based MacBook and send it to the ARM one, it does not work. If I then extract the files and re-zip them, it will work. I guess the problem lies in how the files are zipped, and different mac systems may zip files differently when using the in-built zip tool.

The ARM MacBook:

(with Firefox 103.0.1 64-Bit)

[dfuchss]

Maybe the way to go is to Zip the files directly in Java. Java has Zip Support maybe then the problem will not directly occur.

[nestabentum]

@tsaglam I found the issue: I falsely assumed that the submission file name would always have the same index when splitting its path, as this was always the case when I tested the viewer. The submission files in my zip always had the path result/submissions/<submission-file>, therefore I extracted the submission file name from splitting the path at / and accessing index 2.
The submission files in the zip you provided have the path submission/<submission-file>, for whatever reason.

Consequently, I changed the file name extraction to locate the index of the submission folder and find the submission files by a accessing the the found index+1.

The report viewer has no problem handling empty files, nevertheless I changed how they are displayed: Instead of showing one empty line, the text "Empty File" is displayed.

PR #573 .

@dfuchss this might be worth implementing. It could maybe also eliminate the need to check for the __MACOSX folder, like my current solution has to. Of course, this requires Java to not use the OS's built-in zip compression. But thinking about it, the check does not hurt as users could still unzip and zip their report with what and why ever they want to.

[sebinside]

@dfuchss @nestabentum We should totally discuss this feature in the next dev meeting as it goes in line with our updated requirements on local execution vs. deployment of the web viewer. One could even argue that (in our current world view), a zipped result should be the new default. I also already added this to the main report viewer issue #357.

[sebinside]

Closed with #573.