Wrong calculation for initial file size

Bug

Expected Behavior

Given a gzipped file in url When loading the page Then the calculated file size is correct.

Given a cc.json file in url When loading the page Then the calculated file size is correct.

Actual Behavior

The calculated file size is always 13 for gzipped files and 15 for not gzipped files.

Steps to Reproduce the Problem

1. copy app/codeCharta/assets to dist/webpack which is the static file server in dev mode
2. run in dev mode (npm run dev)
3. add a debugger to the calculation
4. open in browser e.g. http://localhost:3000/?file=assets%2Fsample3.cc.json, http://localhost:3000/?file=assets%2Fsample2.cc.json&file=assets%2Fsample3.cc.json or http://localhost:3000?file=assets%2Foutput.cc.json.gz

Technical analysis

Calculated file size for gzipped files comes from response.body.toString().length . response.body is a blob in that case. Therefore response.body.toString() is always the string "[object Blob]" and its length is 13

Calculated file size for not gzipped files comes from response.body.toString().length . response.body is an object in that case. Therefore response.body.toString() is always the string "[object Object]" and its length is 15

Note that previous urlExtractor.spec.ts mocked the http get request falsely as below. Therefore some tests had a different file size. But in reality initially it receives always a blob or an object. Also note that this complete parsing gets only called for initial map loading. Manual uploading a map doesn’t utilize the urlExtractor.

$http.get = jest.fn().mockImplementation(async () => {
			return { data: '{"checksum": "fake-md5", "data": {"apiVersion": 1.3, "nodes": []}}', status: 200 }
		})

Open question

Do we need the calculation, when it currently is a “random small hardcoded number” and no one has noticed?

What is actually the correct calculation? Should it be the length of (unzipped) text content of file? It seems to be used for map size resolution somehow? (see getMapResolutionScaleFactor within codeMapHelper.ts.

Specifications

• is released in online-demo: yes
• CodeCharta Version: 1.109.1

[BridgeAR]

Seems like this is unblocked now? 🎉

[ce-bo]

We need the correct file size to handle the visualization of big maps and to avoid crashes of CC due to performance issues. Hence, it should be fixed.

In more detail: We try to scale down the resolution of the rendered city map according to the map size to prevent rendered maps with a resolution, for instance, of 50.000 x 50.000 pixels.