Remove the message size restriction and fix the validation of images #2472
Conversation
SuperNascher
changed the title
SuperNascher
force-pushed
the
message_size
branch
from
c20e7a6
to
380ee61
Compare
SuperNascher
changed the title
|
Code-wise, PR looks fine. But we need to tread carefully to ensure we don't do something stupid. We need to test how Qt reacts with big HTML documents in the log view. That's the thing I worry about. Alternatively, we could perhaps limit the documents by area instead of the arbitrary restrictions we currently use? I'm thinking: the inserted log item must not exceed an area of 4096x4096 (16777216), or 2048x2048 (4194304) -- and perhaps those values are too optimistic. This would a square 2048x2048 log entry. But also a log entry that's sized at 300x11288, or at 11288x300 -- both areas are smaller than 4194304. |
|
Some screenshots with and without the restriction: Without restrictionWith restrictionThe HTML text from the screenshots: |
SuperNascher
force-pushed
the
message_size
branch
from
1ffdc2d
to
6437183
Compare
|
@SuperNascher I am more concerned about memory usage with large HTML messages, and log performance in general with big messages. Have you tested any of that? :) Also I'm interested HTML that displays something huge, but is actually very small in source form, i.e. |
| return errorMessage; | ||
| } | ||
| int messageSize = s.width() * s.height(); | ||
| int allowedSize = 300 * 11288; |
There was a problem hiding this comment.
Should include a comment about this being a "max area", so as long as the bounding box of the rendered HTML stays within this area, it will be allowed.
Also: why 300 * 11288 instead of something like 2048x2048?
|
@mkrautz
|
|
@SuperNascher can you elaborate on what the strikethrough in the message above means? :) |
|
My first thought was, that it is not possible to use width and height to create large HTML elements. Qt allows the use of these styles only for pictures, tables and “horizontal rulers”. Another possibility to abuse the text messages is to use margin-* (margin-top, -bottom, etc.) and padding-* to “extend” the messages. Here are some examples: or And now comes the question, how Mumble should treat these messages. An approach to the solution could be to create a regexp filter that deletes the margin and padding styles before the validation of the message begins. Another possibility is that Mumble still checks if the message is smaller than the width of a half screen size. If the message is bigger than the message will be posted as HTML source code. |
|
@SuperNascher So you're saying that if a message includes, say, an image with width=50000 height=50000, then it will not be filtered by the check in this PR? I'm just trying to understand what the problem is. |
|
Yes, the image will not be filtered by this check. The big image even works on the normal mumble version. I have created an issue #2477. |
|
@SuperNascher Now that we've fixed the big image problem -- does this fix now catch them? |
SuperNascher
force-pushed
the
message_size
branch
2 times, most recently
from
1ddbe6b
to
e72a029
Compare
| } else { | ||
| return errorMessage; | ||
| } | ||
| if (!valid) { |
There was a problem hiding this comment.
I would move this above qtd.adjustSize(), etc. -- valid is already set there, so we don't need to wait to use it until we're down here.
|
Also still interested in some performance/memory usage. I think it should be possible to get Qt to render somthing that isn't an image, that is still large?... |
Currently, Mumble has a restrictive message filter that will filter away messages that are larger than the screen. A filtered message is replaced with the text "Text object too large to display". This commit replaces the existing size filter. Instead of using the screen size to determine whether a message is too large to show, Mumble now checks whether the area of the received message exceeds 2048x2048. For example, this will allow messages with sizes such as 500x8388 or 1500x2796 -- or simply 2048x2048. As long as the total area of the rendered message does not exceed 2048x2048 -- in which case the "Text object too large to display" will be displayed. Fixes mumble-voip#2467
|
I am done with the tests. I used QElapsedTimer to track the executing time of validHtml and ps to track the process and memory usage. Here is the source code for testing (works only on Unix systems): https://n0paste.tk/wNS2zJX/ I have tested three messages and these messages has been tested three times. First message: https://n0paste.tk/gLH94fJ/ Used terms: PR Client: The Client with this Pull Request First message
Second message
Third message
Summary of the messages
|
SuperNascher
force-pushed
the
message_size
branch
from
e72a029
to
3d082c8
Compare
|
Sorry that I post the results today, but my first objective was to test the changes on a 1GZ ARM device, but the compilation for the device took to long, so I have used my PC. Here are the test results of sending the message ( Used terms: Mumble PR Client: The Client with this Pull Request
Summary
|
|
LGTM |
A rework to #2049 and it fixes the validation of image URLs.