brr.fyi/posts/laundry-at-the-end-of-the-world uh... why the images appear backwards here?

(images render fine on FF91ESR)

brr.fyi in fact, many of the photos on this blog render upside down in SeaMonkey

I smell CSS

given that "view image" renders them correctly

... no, that's at the http level, no CSS involved

same, pictures render upside down in pale moon

franstam: Ibet thisis pictures taken froma cellphone and depending on wich orientationyou had the phone in the actual image might be upside down but is something in the metadata for the image file that tells you how to l it to account for this we seem to incorrectly ignoring.

franstam: I bet this is pictures taken from a cellphone and depending on which orientation you had the phone in the actual image might be upside down but is something in the metadata for the image file that tells you how to account for this we seem to be incorrectly ignoring.

Mind you, not all pics render upside-down, just some (and yes, the blog author is using a cellphone, but from the screenshots I've seen it's not an iPhone)

but weirdly enough, Modern Browsers™ do render them OK, so may be some EXIF shenanigans then?

so pictures taken with the camera on top if you havethe phone hoizontal will be right side up if camera is on the bottom might be upside down and anything using the front facing camera will be mirror imaged

to,mman does not matter depens on which way you hold the camera if you have the camera upside down then pic will be upside dows but I bet there is meata data that says image should be dliped vertically which we ignore.

I should bring that theory to test with my cellphones, would be a interesting experiment indeed

if camera is in top left when you take tha shot I bet it displays correclty if the camera is in bottom right I bet it dispalys upside down

take photos, load on SeaMonkey, check

my guess is also that the person whose blog thes pictures are on is left handed bcause he takes pictures woth the pne on bottom firght becuase that makes the wcontrols be on the left.

if u download the pics lemme check the exif info is that possible?

i am just guessing here I would have no idea what to look for

but i know i can take pictures with my phone in what I would consider to be upside down but the phone reveres the image so it looks ok when I take the picture but I bet those would be what we render upside down

WG9s if you pick the orginal url not upside down so something website

there must be something we are ignoring that says invert this image verticaly for display

aha.... i download the image, and disable auto image flip using exif info, and the image is upside down

lol seems we are onto something here

frg_Away: but then that does not esplain wy it displays correctly with latest firefox.

so seems issue is we do not support auto image flip

brr.fyi/media/wastewater-plant/wastewater-plant-icon.jpg this one seems to be edited and yet it's flipped

download, open with a standalone viewer, renders OK

EXIF metadata says: Orientation: down-right

...my Alcatel cellphone doesn't tag orientation

tomman: so seems if camera is down right image shows upside down so we ignore the metadata orientation

it seems so

that means sometime in the future, Mozilla started obeying EXIF orientation metadata

probably a later mozilla patch we need to take to fix this or perhaps a later third party image decoder

OK, my Redmi Note 11 indeed uses EXIF orientation tags

a normal image says Top-left

so I guess we do things fine if camera is at top edge of the orintation we used to take the picture otherwise it is shown incorrectly

and for things taken on an iphone for videos issue is if camera is on the top volume controls are on the bottom so perhaps inaccessible during the video because of camera stand.

so if you orient the phone so you can get to audio controls the entire video might end up upside-down.

aAAAAAAAAAAAAAAAAAA

Thank you Beela for your input!

Bug 1367251 ?

oooh, it's SeaFox indeed

it enforces a margin and aligns images to the left

Old Default Image Style not only counters that, it also let you customize backgrounds, and even abuse it to inject custom CSS

and it works fine except that sites enforcing CSP break it, and that addon has been unmaintained for nearly 8 years

and from SeaFox addon page:

"- Old Default Image Style: Sea Fox uses a different method to restore the old top level images look."

doesn't help that Sea Fox development also ended years ago

options: either fix Old Default Image Style to deal with CSP crap (I really like my margin and white backgrounds!), or fix Sea Fox to actually center images (also OK)

...found it

it's not even JavaScript but CSS!

seafox/chrome/skin/TopLevelImageDocument.css

that's the one that fixes the background color, adds the margin... and forces the stupid left alignment

now I have two possible courses: 1) kill those and rebuild the addon, or 2) counter a hack with another hack: what about userChrome.css?

oh, it's not userChrome but userContent.css, D'OH!

tomman: 3) make an addon that overrides TopLevelImageDocument.css with your hacks (or perhaps that's 1)?)

I'm kinda close to it

if I disable a couple rules (text-align:right, position: static), I get centered images but lose the margin I want

oh, it's resource://, not chrome://, so IIRC not overridable :-(

how's the margin you want?

8px is enough

wat, I can't override it with userContent?

not even if I use !reallyImportantAndIMeanIt? :D

no, I was saying that for an extension

chrome.manifest has an override directive, but it doesn't work with resource://

in the case of Sea Fox, it overrides resource://gre/res/TopLevelImageDocument.css with chrome://global/skin/media/TopLevelImageDocument.css

the naive option would be to zap the contents of the latter

injecting CSS elsewhere requires dealing with CSP crapola

but... Palefill does deal with CSP crapola

override chrome://global/skin/media/TopLevelImageDocument.css chrome://seafox/skin/TopLevelImageDocument.css

(from the seafox chrome.manifest)

(that's a different file than the resource: one, isn't it?)

gah, this CSP junk is way over my paygrade :D

(also Palefill deals with SCRIPTS, not stylesheets)

but really the proper way would be to fix Old Default Image Style, as it actually allows for customizing stuff

And here comes to Ye Olde Centering Junk On CSS aka "Welcome to Hell"

you're supposed to place your element to be centered (that is our <img>) inside a <DIV> or something else

a <img> inside a <body> won't do because HTML GAAAAH!

I can get my image centered with just position:absolute, margin: auto, and top/left/right/bottom: 0, but lose the margin

with padding I can get the margin and keep things centered, but then I introudce unwanted scrollbars

at this stage it has become your traditional CSS challenge

...and now I've just discovered the joys of CSS flexbox!

why aren't all the directory provider directories simply mapped to resource uris.. that way simple read doesn't require using the dir provider service

i mean other than the issue with the resource uri

but they could map it into the chrome url as well

GAAAAH CSS!

I can center my image perfectly in so many ways, but not with a border

either at least one of the borders gets eaten, or I get scrollbars instead of image+border fitting to height

why the W3C hates centering stuff so hard?! This shit is not new, y'know...

Anyway it seems I gonna give up on the margin idea, as I value more centering than padding/margin/border/whatever

any chance you could set margin and border on body, not img?

ah, I see, that probably is only possible without position: auto

tomman: what about box-sizing: border-box? developer.mozilla.org/en-US/docs/Web/CSS/box-sizing

seems to get rid at least of the scrollbars when I use width: 100%; height: 100%

njsg: OK, border-box seems to indeed help!

So basically here is what I got so far:

1) forget about messing with <body>, no CSS flex, no width/height set

2) Leave the default centering stuff on built-in TopLevelImageDocument.css (text-align: center; position: absolute; margin: auto; top/right/left/bottom: 0) since that actually works for centering

3) Add a fake transparent border to <img> and set box-sizing: border-box;

now need to figure out where to place all this: either hijack Sea Fox's TopLevelImageDocument.css (since it has some weird ideas there), or abuse !ReallyImportantAndIMeanItOrElseTaiwanBlowsUp on userContent.css

had to go the way of editing Sea Fox's TopLevelImageDocument, of course

doing stuff the userContent.css would break the Internet in very... artistic ways

now I get my centered images plus margins, save for a marginal case *ba-dum-tss*

if the image is ALMOST the size of the viewport, the browser won't let me zoom it out or in at all

and I lose like half of my top border (I ended with 16px, lose like 8 pixels) for whatever weird reason

for all other cases it works OK

I still insist that the proper way would be fixing Old Document Image Style to cope with CSP, but that's a hell I'm not THAT interested to get into

at least not without good help, and a exorcism or two!

Regarding the flipped images on brr.fyi: while messing with my image margin stuff, I noticed something

if the image is opened in a standalone tab, browser applies image-orientation: from-image (from resource://gre/res/TopLevelImageDocument.css)

but on the blogpost that rule appears nowhere on the default stylesheets

yes, the default used to be something else and was changed to be from-image in bug 1607667

"Chrome is shipping the change to make from-image the initial value in Chrome 81 twitter.com/argyleink/status/1214616780200562690 so now may be a good time for us to make that change too."

not sure it's that, could be something else, but at least sounds like it could be that

the very first comment depresses me

one moment

there was also a site compatibility note that now links to a dead website

I'll quote again «The only consolation is that, someday, the spec will become the standard and stop changing.» from marc.merlins.org/htmlearn/netscape/tables.html

"It turned out Chrome 81 already shipped this change (and broke Slack) so there’s no reason for Mozilla to stop shipping."

heh, a change broke broken web junk, lovely~

I guess I'll be adding image-orientation: from-image; to my userContent.css in the meanwhile~

if that is the problem, then img {image-orientation: from-image;} in userContent.css would make sense as a workaround. I suppose there are cases where it won't be enough (image-orientation: initial?), but hopefully that's not something used often?

What site would rely on different defaults?

at least I'm not enforcing it via !important, so if a site for whatever weirdass reason wants to flip images on its own, so be it

in any case this was a very weird issue that nobody noticed because it's so niche...

brr.fyi/posts/credit-card-shenanigans no, THIS is a niche bug :D

:-D

try explaining that to your bank, that Antarctica are like many separate countries on the same road

wonder if Wells Fargo still run that couple ATMs down there

shouldn't really be a far-fetched idea, they probably already need to have something for bank card transactions across borders, a question is why they didn't have that in this case, but I'm guessing it was too much trouble and this was the solution people running services there could deploy

the only one that works is the <img> with explicit image-orientation: from-image; (and in my case, the very first <img> after adding that rule to userContent.css)

everything else ignores both EXIF metadata _and_ the rule, yay~!

FF91ESR does everything right, as expected

"I really think producing JPEGs that use the EXIF orientation is a bad idea. And I worry that importing EXIF orientation as a Web feature adds complexity and will create more problems."

tomman: i want you to think about your statement that esr91 does everything right

that ship has sailed the day Apple and camera OEMs started using it, dude

tomman: could that be bug 1650715?

the background-image, not Apple

njsg: this is one of those cases where metadata actually matters

if the metadata says "the image is flipped, unflip it when rendering", then the user agent is supposed to unflip it

I took a photo with my camera, I don't care how the camera stores it as long as it is in standards-compliant formats (and EXIF metadata is clearly part of it), hence I see no point to argument that

display my photo as intended, full stop.

if your tools produce broken images, fix your tools, don't impose more brokenness on web browsers!

at least this was one of the rare cases where the answer isn't "Chrome did it first" :D

no, wait, someone at Google figured out that his/her/its iPhone were generating images that "flipped" on Chrome and Apple sure as hell won't "fix" what it isn't broken

Meanwhile, at Stately Wayne Manor..