Was this forgotten?

Can I get a review on this?

In D22864#505559, @ngraham wrote:

Can you describe what problem this is fixing, or what improvement it produces? It's not clear from your Summary section.

In D22865#505628, @davidedmundson wrote:

and it looks unrelated to the rest of that changeset.

It does.

Do you have a commit account?
If so, I would suggest you merge after Saturday's tagging.

In D13314#361034, @astippich wrote:

@miklosm shall I land this for you?

In D13316#327854, @ngraham wrote:

@miklosm, can this go in now, or it is dependent on either of your other two patches?

In D13315#327933, @dfaure wrote:

No, no. Too unreliable and against the MIME spec.

You're testing it for the ideal case, images, which have proper headers.
But there's no reliable "magic" (determination from content) to distinguish for example MSWord .doc vs Excel .xls, because it's all the same OLE storage format. Or many other cases like this.
This is why the MIME spec (which is implemented by mimeTypeForUrl) says: if the extension is known and matches a single mimetype, then that's the one.
This allows users to have control, rather than fuzzy algorithms.

Determination from content is only used when there is no extension, when multiple mimetypes are associated with the same extension (example: *.ogg can be audio or video), or when the extension is completely unknown.

In D13316#288653, @elvisangelaccio wrote:

I guess this change makes sense (given that we are in the jpeg plugin), but what about QImageReader::decideFormatFromContent() ?

BTW the updateInterval, which caused the conflict, is not as useful as it sounds, because the data source sends new data at a fixed 1Hz frequency.

Rebased on current master

In D12857#274212, @ngraham wrote:

Do you need someone to land this for you, Miklós?

In D12857#273608, @ngraham wrote:

Screenshot please! See https://community.kde.org/Infrastructure/Phabricator#Include_some_screenshots