Include the page URL in the screenshot image
Categories
(Firefox :: Screenshots, enhancement, P3)
Tracking
()
People
(Reporter: sfoster, Unassigned)
Details
Via https://connect.mozilla.org/t5/ideas/include-url-when-taking-a-screenshot/idi-p/13525
"When you do screenshot things for your records/files, include the full address as shown in the URL bar."
It would be nice if Firefox screenshot tool would do that, especially for full page screenshots:
either display the URL
- in the title
- or in the picture itself
- or as meta data into the file
This could be interpreted a few ways. We could add the full URL to the PNG metadata. Some image/photo software exposes that metadata and it would be retrievable in archiving scenarios. It is also invisible otherwise and presents a potential privacy problem, so we would need to make this opt-in.
Putting the URL in the image itself - in the same way you might get a date stamp on a photo - is another possibility. Again this would need to be opt-in, and I'd expect the preview to show it so the user can assess the result. We would have to potentially truncate URLs to fit.
Using the URL instead of the page title in the filename doesnt seem as useful to me, as we have to strip out a lot of characters to make a valid filename. We have had other suggestions in the past about making the filenames configurable though and including at least the host/domain name as an option there seems possible. That is tracked as bug 1768547.
|
Reporter | |
Comment 1•2 years ago
|
||
If we did the metadata thing there are a couple of open questions:
- Which EXIF tag to use? ImageDescription? There are many but none that seems to directly fit the use case so I'm open to suggestions.
- How to write the EXIF tag. Currently Screenshots calls drawSnapshot to get its pixel data. We would need access to lower-level APIs to write the exif data in there, or for the pipeline that underlies drawSnapshot to allow metadata to be passed through to the correct layer where the image and its metadata are created.
|
||
Comment 2•2 years ago
|
||
There's some discussion of this here.
|
||
Comment 3•2 years ago
|
||
Is it possible to add a step in the screenshots code that writes the exif data to the png before handing the finished produce to the user? The exif data shouldn't be complicated, finding/writing a little exif js utility shouldn't be too hard I don't think. Adding the ability to write exif metadata in our C++ image encoding pipeline would probably be more work because it's in C++ and the interface is more general so decisions on how to shape the api would be in a more general use case context.
|
|
||
Comment 4•2 years ago
|
||
Ashley reminded me that png has a text chunk type which can hold arbitrary text. That is another possible place to store the url. I think handling that would be similar from a technical perspective as my previous comment.
|
|
Reporter | |
Comment 5•2 years ago
|
||
I see this exif-js repo, but it seems to be only for reading exif data from js. I'll have to keep looking around to see if there's a good license-compatible library or if the writing is something we'll need to do ourselves. But I agree that this is something we can handle within Screenshots rather than the platform layers.
I'm still not sure exactly which tag or what metadata specifically we're going to add the URL to. The link in comment 2 has some suggestions and ends up talking about RDF, but I'm not sure how PNG (a binary format) and RDF - which I normally associate with sgml/xml documents would interact. But the specifics are potentially a bridge we can cross when we get to it.
|
|
||
Comment 6•2 years ago
|
||
The writing should be pretty easy, you don't need to touch the binary data from the screenshot png, just append to it. And it would be some boilerplate bytes, length of the data, a checksum, and then just the text you want to append.
|
|
Reporter | |
Comment 7•1 year ago
|
||
We've ended up with 2 bugs on file for this, each with relevant and important pieces of the puzzle. I'm getting the 2 confused constantly so I'm going to dupe this over to bug 1798543 which I believe was filed first, and which I've most recently commented on.
Description
•