Open Bug 1935810 Opened 9 months ago Updated 2 months ago

Setting kMDItemWhereFroms to really large data:image/png urls (for downloads from Screenshots) breaks SugarSync

Categories

(Core :: Widget: Cocoa, defect, P3)

Firefox 133
Desktop
macOS
defect

Tracking

()

People

(Reporter: jscher2000, Unassigned)

References

Details

When downloading a screenshot, Firefox sets the data URL of the screenshot image as the source URL.

On MacOS, Firefox then sets kMDItemWhereFroms (file metadata attribute) to the data URL which renders the file incompatible with SugarSync. Reported on SUMO at https://support.mozilla.org/questions/1477573.

Noting that bug 1374027 -- to allow users to pref off this metadata attribute -- is languishing, can Firefox simply never set this attribute to a data URL for an image as a workaround?

I don't know the best way to implement that, but one could check the sourceURL in
AddOriginMetadataToFile() and return without saving if it's an encoded image?

A simple fix would be to copy the behaviour from Windows and write about:internet in cases where we don't get a "normal" url.

A more proper fix would be to unify the Windows and macOS behaviour; unfortunately they appear to have been written by different people at different times in different places with different languages and different IO and sanitization behaviours, and this is bad. 🙃

It's perhaps also worth noting that the about:internet value is making people unhappy who would prefer that we dig deeper to find something resembling useful information (maybe via the precursorPrincipal information for null principals, to find the https or similar URL from which we originally downloaded the file).

If the thing that is objectionable to SugarSync is purely the size of the metadata, another workaround here could be if screenshots used blob URLs instead of data ones. This would be better anyway - it would also avoid issues with e.g. bug 1924027.

Niklas/Sam, do you know why screenshots uses data instead of blob URLs, if we have a bug about this already, and/or if it would be easy to fix?

Flags: needinfo?(sfoster)
Flags: needinfo?(nbaumgardner)
See Also: → 1924027
Summary: Setting kMDItemWhereFroms to data:image/png (for download from Screenshots) breaks SugarSync → Setting kMDItemWhereFroms to really large data:image/png urls (for downloads from Screenshots) breaks SugarSync

(In reply to :Gijs (he/him) from comment #1)

If the thing that is objectionable to SugarSync is purely the size of the metadata, another workaround here could be if screenshots used blob URLs instead of data ones. This would be better anyway - it would also avoid issues with e.g. bug 1924027.

Niklas/Sam, do you know why screenshots uses data instead of blob URLs, if we have a bug about this already, and/or if it would be easy to fix?

The why is just because that's what the extension did and we didn't fix it yet. We have bug 1908205 on file, and a WIP patch on there, but no short-term plans/availability to pick it back up.

Flags: needinfo?(sfoster)
Flags: needinfo?(nbaumgardner)

We're not quite sure what the implications of switching to about:internet would be on macOS, or if just never saving data URIs as metadata would cause a security regression of some kind.

Moving to cocoa where hopefully people have a better sense of the implications there.

Component: File Handling → Widget: Cocoa
Product: Firefox → Core

The severity field is not set for this bug.
:spohl, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(spohl.mozilla.bugs)
Severity: -- → S3
Flags: needinfo?(spohl.mozilla.bugs)
Priority: -- → P3

The bug as reported here might now (140+) be better because of the screenshots change in bug 1908205? jscher, could you doublecheck? Thank you!

Flags: needinfo?(jscher2000)
See Also: → 1374027, 1908205

I posted a request in the SUMO thread but haven't received any feedback. As a Windows user, I can't test it myself.

Flags: needinfo?(jscher2000)
You need to log in before you can comment on or make changes to this bug.