roadrunnertwice: Two fir trees in bright sunlight. (Portland - Farragut)
Nick Eff ([personal profile] roadrunnertwice) wrote in [site community profile] dw_beta2020-05-06 11:02 pm
  • Add Memory
  • Share This Entry

The "Updated Miscellany" beta

Hello! As of late April 2020, there are two new beta features available on dreamwidth.org. You can turn them on at the usual place.

  • The first one is Two-Factor Authentication. 2fa is an optional thing where you log in with your normal password, but then have to confirm the login with an app or security key before you can actually get in. You might have used it for your email or for important work accounts; soon you'll have the option of using it on Dreamwidth.

    Important note: currently, we only implement the setup phase. You can configure a 2fa device, but DW won't yet actually use it to enforce access to your account.

    The rest of this post isn't about the 2fa beta, because I don't know as much about it! There will probably be a more detailed post about it later, once we start implementing real login protection with it.

  • The second one is called Updated journal page components, because it's extremely miscellaneous and I needed to call it something. That's the one this post is about.

    tl;dr: better comment pages on your telephone. Especially if you use Android and it usually looks like a bomb went off in the reply form.

What's in the Beta

This beta messes with the following Stuff:

  • Site-skinned comment pages.
    • They 🌻 work on mobile 🌻 now.
    • Should look mostly the same, with very minor differences.
  • The "more options" reply form.
    • Similar functionality as before, but it now resembles the quick-reply.
  • The icon browser (for paid users).
    • It's new and improved. This is an update to the rewritten icon browser that was previously available on the beta new entry page.
    • Does the same stuff as the previous icon browser, but works better on mobile and makes better use of available screen space.
  • Icons pages. (https://<USER>.dreamwidth.org/icons)
    • Same thing as comment pages: better on mobile, mostly unchanged.

(You can see why the name of the beta was tricky. These things don't SEEM like they should be related at all, but due to Reasons, they are.)

Known Issues or Non-issues

Stuff we're already working to fix:

Stuff that's intentional, so we're not working to fix it:

  • On Tropo skins (red and purple), the comment page font size (13.6px) is a little bigger than it used to be (12px).
    • It's still smaller than the widely-agreed best practice on the web (16px), but it'll be a noticeable change for DW users. We hope you can get used to it in time!
  • In "more options," the spellcheck checkbox is gone.
    • That spellchecker is outclassed by the built-in spellcheck in most web browsers, so we're gradually sunsetting it.

Stuff we already fixed:

  • Extra "Thread" link in each comment's footer.
  • The "in-between" reply page you land on if you need to fix a mistake or do a captcha is now in the beta. (https://www.dreamwidth.org/talkpost_do)
  • The comment preview page is now in the beta.
  • In the "Drifting" journal styles, the "more options" form got pushed down past the end of the sidebar content.
  • style=light (and the Lynx site skin) was Wrong with the beta enabled — too many non-browser-default colors and fonts.
  • New icon browser cruelly sent your keyboard tab position to Oz when you were done using it, and couldn't really be navigated with the keyboard anyway.
  • On Gradation skins, the comment page font size was smaller than it should be.
  • The nav/action box on entries could sometimes get too close to large mood theme icons.
  • Code blocks (like <pre><code>...</code></pre> as opposed to plain <code> spans) looked bad.
  • The username indicator above quick-reply looked weirdly small.
  • On site skin pages, you couldn't resize the reply form to be wider than its starting width.

How to Help

Turn on the beta, use it for a while, and let us know what's not ready yet!

  • Please read the "known issues" section above before reporting problems.
  • Please include your operating system version and your web browser version when reporting something!

What we most want to know is:

  • Is anything unusable or broken in your browser, especially in the site-skin comment pages?
  • Does the new icon browser break? When and how? What sucks about it?
  • Does the rearranged "more options" reply form break? When and how? What sucks about it?
    • (Please try living with this one for a day or three before declaring it wholly bad. I know moving controls around in the reply form is inherently traumatic, but we're trying to get this right for the long term on both mobile and desktop. Thank you for your patience AND for your feedback.)

Many thanks to the users who have already reported issues! 💖

Flat | Top-Level Comments Only
apollymi: Hicks training Ripley w/weapons, Ripley looking over shoulder at him, text reads "You started this. Show me everything" (Aliens**Hicks/Ripley: Show me everything)

[personal profile] apollymi 2021-02-08 04:14 am (UTC)(link)
I feel like I've seen this listed before as a known issue, but...

When I am looking at the beta Create Entry page on Google Chrome with my Mac, the tags section looks like this:


I do not see entries this way on Opera or Safari... or Windows Chrome.

I'm using Gradation Vertical, on an Apple running OSX 11.1 Big Sur. I'm on Chrome version 88, but it has existed previously.
roadrunnertwice: Rebecca on treadmill. (Text: "She's a ROCKET SCIENTIST from the SOUTH POLE with FIFTY EXES?") (Rocket scientist (Bitter Girl))

[personal profile] roadrunnertwice 2021-02-08 05:44 pm (UTC)(link)

Can't reproduce this, but very curious about it.

Hey, are you comfortable with using your browser's "inspector" dev tools? Would you like to be? Since I can't reproduce the bug myself, I'm at the mercy of whatever I can learn from someone who IS seeing it.

On Mac Chrome, the shortcut to open those is cmd+option+i. If you open it while you're viewing the create entries page, you can spy on all kinds of shit. What I'm curious about first is:

  • Look at the "elements" tab and find the top-level "<html>" element for that page -- it should have a bunch of classes on it, like honestly way too many classes.
    • Does it actually have a bunch of classes?
    • Are "fontface" and "generatedcontent" among those classes? Or are they missing?
  • Look at the "console" tab -- are there any suspicious warnings or errors in there?

Alternately, if you can figure out anything else about when that bug happens or doesn't happen, I'd love to hear it.

apollymi: Bakura & Kaiba fanart commission, text reads "Apollymi" (Default)

[personal profile] apollymi 2021-02-08 06:11 pm (UTC)(link)
And now that I'm trying to reproduce it, it's loading perfectly. (Behold the power of having a second set of eyes looking at it?) But to answer the questions...

The HTML element does have a hugely ridiculous number of cases attached to it. "Fontface" and "generatedcontent" are among the cases I see.

Under the console, I see one error warning:
Assertion failed: Input argument is not an HTMLInputElement.
getFormProfile @ onloadwff.js:71.
roadrunnertwice: Parking lot stencil: "ALL TREES WILL BE TOWED," with tree glyph in "no" sign. (All trees will be towed)

[personal profile] roadrunnertwice 2021-02-08 06:27 pm (UTC)(link)

Oh huh, it looks like that console warning has something to do with the LastPass extension. I wonder if maybe a bug in an extension was causing the problem, and then they pushed a fix for it recently?

That, or maybe the bug depends on the order that certain things happen. 👻 Love it when that's the case. 😣

Well, at any rate! Glad it's loading right for the time being, please let me know if you learn anything more about it. 👍🏼

apollymi: Bakura & Kaiba fanart commission, text reads "Apollymi" (Default)

[personal profile] apollymi 2021-02-10 07:56 am (UTC)(link)
Well, somehow today I managed to reproduce the error. The difference seems to be that I typed an entire entry and then came back later to save and tag it.

(I'm tired and not sure I said that right: I typed up an entry but didn't hit "Post Entry" at the time. A couple of hours later, I realized I hadn't posted, so I came back and started doing the tags. That's when I got the error.)

Looking at the inspect page elements, I see that "fontface" is in the HTML element, but "generatedcontent" is not. Instead, it shows "no-generatedcontent".

Does this help in any way?

Under the console tab, I see the same error code:
Assertion failed: Input argument is not an HTMLInputElement.
getFormProfile @ onloadwff.js:71
This time it has the number 11 in front of it.

If I disable the LastPass extension, I still see the same HTML elements, but there are no errors in the Console. I also tried disabling all extensions and am now getting the same HTML elements all the time.
Edited 2021-02-10 07:58 (UTC)
roadrunnertwice: Rebecca on treadmill. (Text: "She's a ROCKET SCIENTIST from the SOUTH POLE with FIFTY EXES?") (Rocket scientist (Bitter Girl))

[personal profile] roadrunnertwice 2021-02-11 06:28 am (UTC)(link)

That IS helpful! Well... it’s interesting, at least. 😅 I’m not wholly sure what to do with it yet!

Those too-many-classes are part of a library called “modernizr,” which ironically is fucking antique. It’s what people used to use for feature detection before css feature queries existed. If it’s starting to rot in modern chrome versions... well, it would take the cake.

Knowing that the “generatedcontent” part is the issue is definitely going to be useful once I have time to chase this more, so thanks for your diligence! I have no idea whether the delay between write and post is relevant, yet, but it’s good you mentioned it just in case.

roadrunnertwice: Dialogue: "I have caught many hapless creatures in my own inter-net." (Hapless creatures (Rainy Days))

[personal profile] roadrunnertwice 2021-02-11 09:11 pm (UTC)(link)

Hmm, looks like modernizr tests support for the ::before/after pseudo-elements by adding one to an empty div, setting font size and line height only on the pseud, and then measuring the height of the div. The current version of that sets the height to 7 and then checks if it's >= 6, due to a possible issue with zoom levels causing rounding errors... but we're using an old version of modernizr that sets the height to 3 and checks for >= 3.

So it's highly likely that you're hitting the issue with rounding errors that caused them to change that in the first place... but not hitting it all the time, because of something non-deterministic somewhere. Possibly Chrome changed something in their renderer at some point and it made that kind of rounding error more likely. IDK.

Main point is, probably gotta upgrade modernizr... or just stop depending on it for these, and assume everything supports ::before.

Flat | Top-Level Comments Only