Code has been pushed!

[mark]

Hiya, as per yesterday's announcement, the latest Dreamwidth code has been deployed.

This is the issue/bug/problem tracking post! Please let us know if you see anything... untoward.

Fixed

• Posting an entry would tell you that your password was blank.
• API key generation/deletion was... behaving a little weird.
• Profiles pages were converted to Markdown, but this was too soon. I've put them back to raw HTML, they should look like they did before the push!

Known Issues

• Chrome auto-filling in password forms, when trying to post as the already logged in user, results in an error. Still haven't fixed this one, but we will.
• Reports of logging out possibly not? Need more information, login/logout work for me. Seems transient?

And as a reminder, if you use Semagic et al, please check the link above for information on how to configure it to keep working with Dreamwidth!

Comments

[maximite]

Not sure if this is a bug or a feature so to speak, but the new image zoom in/out function on journal entries seems to be clashing weirdly with images using flex display CSS - the images are displaying as tiny by default and only increasing to the flex container size when clicked. I'm guessing this is related to the Markdown move, but all the other image embeds I have on my journals seem to be working as normal, it's just ones with flex display in particular that seem to have gone wonky (playing around with the CSS elements under .entry-content img seems to indicate it's something to do with the max-width: 100% code, toggling that off returns it to normal but I'm not sure if I can actually override that within the nav code itself because all my minimal css knowledge is from google).

[roadrunnertwice]

Ha, woof. OK: tl;dr: set flex-shrink: 0; on the div that has the image in it.

There's a lot of gotchas to making display: flex stuff size the way you want it to. In your case here:

- You've set a width for the flex-item div that contains the image: ok, cool! IIRC that becomes the default flex-basis for that flex item. That's its starting width.
- But flex-shrink defaults to 1, so if the contents of that div don't push back, the other flex items can steal space from it.
- The global image shrink CSS makes it so images can't push back on their flex item parents; therefore that flex item goes tiny.
- But if you use flex-shrink: 0 to say this flex item can't be stolen from, then you're fine and the image will fill the available width.

Here on DW, the image might still shrink a bit if someone's browser height would be too short to display the whole thing. But that's what the new click-to-zoom thing is for.

Anyway, keeping an eye on flex-shrink should serve you well everywhere; hopefully that also clears up how it interacts with the image shrink thing.

[roadrunnertwice]

This post dedicated to all the hours I spent debugging this exact same behavior trying to keep userpics from shrinking to chiclets in the updated site skin comments CSS.

[maximite]

Excellent, thanks for letting me know! I wasn't sure what the gritty details of the coding interaction would've been to cause that, so the extra info is very welcome (also whoof I do not envy you having to figure that out on the userpics, that sounds like it would've been quite the time)

[icon_uk]

This is proving to be an issue on the community I'm an Admin of.

Posted images defaulting to tiny, but sort of at random.

Forgive my ignorance, but how are you defining "flex display" in this case, just so I can advise posters.

[maximite]

The code explanation above mentions it, but I was using that term because all the affected images in my case were in a navigation code using this code string:

<div style="display: flex;"></div>

It's used for making items respond to the size of other items within the div (in this case, textboxes become narrower to accommodate an image), so in this case the flexibility backfired when the image shrink CSS came in. Basically, it's a problem that's going to come up with more extensively coded posts, whereas direct embeds without any bells and whistles shouldn't be affected.