I'd be great to be able to take a link from an instant message and/or the address of a mastodon status in a browser, and open it in Pinafore to then eg like/bookmark/boost, read thread, find user profile etc.

This would mean Pinafore is listed as app destination, similar to how eg RSS readers, alternate browsers, and IM apps are destinations when opening the share menu from a browser tab.

When selected it would use the search feature behind the scenes and eg expand the first and only result right away, if the URL-like value turns out to indeed yield a result.

I originally thought short/contextless names were only rendered if the instance is the same as your own. But now I'm actually not sure what the logic is of the default web app and/or the default rendering provided by the API for Pinafore (if different).

I think it's important that whatever logic we use is extremely simple and easy to deduce/learn/expect as a user after only a few examples.

Local-only seems fine by me, I wouldn't be bothered at all by seeing the full form for all remote mentions.

A possible compromise could be to eg also shorten the author of the tweet that is being replied to, if and only if eg no local equivalent exists or at least doesn't appear anywhere on the page currently.

Separately from that, it might also make sense to show the full form even for local users if a remote user of the same name is anywhere in the viewport, so as to disambiguate both.

This would also increase the need for a Toot As interface (https://github.com/nolanlawson/pinafore/issues/1808) as the last used instance might not be the one on want to post it to.

@bmcage I stopped using the plugin and added the bits I actually wanted directly to my theme, without external dependencies (source).

There's an unclickable "deadzone" between buttons where the cursor is turned into a pointer for hover, but no action occurs when clicking.

I found this in context of a follow-only toot (where it additonally causes the disabled button to also appear clickable), but the issue applies to regalar/public toots as well.

The pressed state, such as used for the "Unfollow" button, was effectively identical to the background, thus making it invisible.

Brighten it up to fix this. The relative differences are kept the same as before and match the default theme,, e.g. the brightness ranges from (darkest) Unfollow > Unfollow-hover > Follow > Follow-hover (brightest)

	Before	After
Follow
Unfollow

Fixes https://github.com/nolanlawson/pinafore/issues/1880.

I'd like to help fix this as my first patch. I've just gotten the local dev environment working, and now orienting myself with the code base. Could use a pointer on how to go about this :)

resting	hover

For comparison, the Mastodon dark theme:

| |

I note that in this theme, the color does not appear to change on-hover, I'm not sure if that's intentional or not.

Object.assign was introduced as part of the ES6 spec and is still relatively new. QUnit offer broader support since its implementation is relatively simple and this allows developers to decide what their supported markets are, without being limited by developer tooling.

At this point, we support IE9+. When we require Edge 12+, we can use Object.assign() internally.

However, I would support soft-deprecating this method in the public API since it is indeed only meant for internal usage. Then in the upcoming QUnit 3 release, it can become a private utility method.

Interesting, I had not considered those as similar, but you're right. I'd support merging the "test" and "suite" concepts. It might require some compromises, but I think it's worth giving a try.

Currently:

• a "test" is the lowest measured unit, typically executed after the phase where a framework will load the test suites and plan their execution. A framework might measure runtime duration around a test, and e.g. invoke hooks (such as "before" or "after" each hooks). These aren't directly of concern to reporters, but helps illustrate what they relate to.
• a "suite" is used for grouping tests, and suites can be nested.
• the top-most suite is referred to as a "run".

I have not previously seen testing frameworks that allow nesting within their equivalent of the "test" concept. I see that node-tap does allow this. As such, node-tap's tests are effectively a hybrid. Like a "suite" that can also directly contain assertions.

The main issue I see with merging these concepts is that it might affect support for "planning" the execution of a run. Right now, we specify a structure that reporters can read that describes how many tests will execute and in which suites they are grouped, before execution begins.

@isaacs How does this work with node-tap? The TAP spec defines a "plan" (spec), which Mocha, QUnit, and Jasmine effectively implement by waiting until all test files have been loaded, seeing what "suites" have been called, but not actually executing the "test" portions yet. It will then know this information, and then can start execution.

I'm generally in favour of removing the structured plan (e.g. the whole suite structure) since this is afaik never used in practice by reporters. A stream-based approach seems preferable there. However an overall count of planned tests seems useful to keep, allowing reporters to track and communicate a sense of progress toward completion.

This is possible via the lang query parameter. However, it is not promoted (the address bar does not update when selecting a language), which means without looking at the source code it can be hard to guess what the right value is (e.g. nl vs nl-NL).

It also appears to malfunction currently as it only affects the navigation menu. The rest of the page is only translated if you open the page without lang?= and select it from the menu. I've reported this bug at https://github.com/tootsuite/joinmastodon/issues/130

When navigating to https://joinmastodon.org/ and selecting "Nederlands (nl)" from the list, the page is nicely translated (awesome! 👍 )

When navigating to https://joinmastodon.org/?lang=nl-NL the menu bar is translated, but the rest of the page remains in English. This appears to be a bug?

I'd support a limited (opt-out) way to indicate that traffic came from Mastodon or Pinafore. However, I think the challenge with the current patch is that it wouldn't just indicate that, it would also indicate the specific hostname.

This provides a fairly low amount of entropy when the instance in question is using the default at pinafore.social. But in the case of self-hosting or less popular forks/mirrors, this not only says much about the user's profile, it could very well even identify them directly.

After checking the current domain, check the list again for the parent domain.

Also:

• Use location.hostname instead of new URL(location.href).hostname. Most properties of the modern-era URL object also exist directly on Location objects. This includes 'href', but also 'hostname'. Use this directly for simplicity.

• Fix the (seemingly) broken entries for Gutenberg and Notepad, which included a schema and/or path slash, and thus cannot match a hostname.

• Update sites.js to use parent domains by default where possible. For Mozilla and Internet Archive, this means the duplicates can now be removed. For Wikipedia, this means the tipjar now works also when viewing articles such as on en.wikipedia.org, and on zh.wikipedia.og.

Fixes https://github.com/corbindavenport/tipjar/issues/15.

Mute thread and report account are also direct, but those are easy to undo

Reporting an account to admins is not something I would want to do automatically. […]

Indeed, and it isn't. My bad. I meant to say "Mute thread and block account.". As I wrote earlier in the message, "Report" already leads to a modal workflow, and indeed does not and should not do anything automatically from the initial tap.

The pattern of checking A to decide whether B is safe to use is imho an anti-pattern and reduces confidence in the code. This was previously the case for setTimeout, performance and document.

@nolanlawson I don't remember building something user-facing in the past decade that wasn't localised. For me that means I'm very familiar with the "how", yet, on the other hand, very blind to the cost 🙂 Could you elaborate on the kinds of maintenance difficulties you'd like to avoid?

I'm open to anything, but my go-to approach would be to move the strings out, and have the application code call a function that's given a message key, with some optional parameters if needed, and get a string in return. E.g. "You have " + num + " message(s)" might become msg("new-messages", num).

Messages would default/fallback to English so day-to-day we wouldn't need to do much other than edit a i18n/en.json file. Depending on how we handle contributions for translations, you'd either leave it up to pull requests by others to improve/add missing translations, or let something like translatewiki.net do its thing (which would pull the repo daily for any new/changed source messages, and provide a PR with any added/changed translations).

There's indeed a trade-off to be made with regards to which languages to bundle, and how much to optimise ahead of time. Rambling out loud for a bit:

• I suspect the best performance would be achieved by compiling/embed the translations into the components. This would produce a bundle almost the same as what we have today, hiding the indirection. This seems appealing, but I've not found this to work well in practice. It makes it harder to handle message variables I think, requires additional maintenance for the logic of doing that embedding, and would mean one has to create and manage a separate app bundle for each language, and the complexity for somehow switching between them.
• The simplest approach (for the developer) would be to bundle all JSON translation files in the bundle, and access the messages at run-time. This might actually be feasible for Pinafore, if there are only a few dozen or hundred distinct messages, the bundle size wouldn't be very notably increased. In my experience the runtime cost of accessing an object key and performing some light string manipulation tends to be insignificant. But of course, we should measure this. Every app is differnet :)
• If bundling all languages turns out to add too much to the initial download cost, we could bundle only English and fetch other JSON files on-demand. This would mean that, like the separate bundle approach, the user would need connectivity when switching languages. However, unlike with separate bundles, there would be no switching complexity, and it would only be upon the first time a language is switched to. After that you'd keep it in the cache bucket. And upon subsequent updates, you'd always include the current language's JSON file among the preloaded assets.

Having an optional file or directory with message overrides would be cool indeed. That would e.g. allow for themetic or fandom customisations whilst still making it easy to upgrade.

Somewhat related: Would it make sense to adopt a convention to indicate whether a link does something vs starts a modal?

Eg "copy link" directly replaces the user's clipboard. The others could have "..." after then per the desktop UI convention for menu items that have additional steps to them.

For what its worth, I think separate top-level menus or sub menus would clutter the interface, and require more overhead for both scenarios. Finding a meaningful and international icon and being friendly to new users would also be challenging.

However, I do want voice also the concern that a single menu for all items is indeed problematic and prone to error -if- the destructive actions have no confirmation behind them.

I've already lost several toots due to accidental deletions due to this via a different mastodon client I tried, after a mis-tap.

Adding indirection the menu seems undesirable as it means longer paths to discovery and more significant/distracting choices to make. However adding a confirmation to the end of it, I think, could strike a good balance here.

I notice that Mute account and Report toot already lead to modals.

Delete toot is currently direct. Unfollow is also direct.

Mute thread and report account are also direct, but those are easy to undo, and don't produce visible side effects or notifications (as far as I know).

I believe the server generally already fetches mentioned URLs for the open graph / card previews, right?

It's by design and social policy that no previews of toots are shown, however I suppose the server could at least remember that it encountered a fediverse-compatible response, and annotate the HTML anchor link in some way for clients to hook into for native navigation indeed.

Is there an upstream issue for this?

Would this be a standard preference in the account settings, implicitly applied to all clients and interfaces?

Or as a local feature within the main web app, and/of for individual apps to implement locally? I've seen some apps already support local filters and queries on the timelines. I don't know how those current work, though, or if they're efficient.

I'd love to help out with a Dutch translation.

If you're interested in levering an open platform, then translatewiki.net could help you get a wide range of translations for app on an on-going basis, including peer review from non-technical volunteers. I've worked with them before and could help set things. Practically speaking they'd provide periodic pull requests with semi-automatic exports of the latest string sets.

The welcome screen contains a spelling mistake in the link to the privacy policy. It should be spelled Privacybeleid, and not Pribacybeleid.

The same word also appears elsewhere in the application (post-login) where it is correct already, without spelling mistake.

The typo was introduced in https://github.com/ReticentJohn/Amaroq/commit/15f519a41cd6891257826ea282b669d41dae0267.

Each time when opening the app, there is a very brief flash of the login screen, as if I was not logged-in. It feels like this is unintended and might be a bug.

Pitch

Right now I find myself putting RSS feed links into my bio with an emoji, like so:

• https://mastodon.technology/@krinkle
• https://polyglot.city/@krinkle

I'm proposing we add something like this (but perhaps not as prominent) to the "public web UI".

(Perhaps to the web app as well, in a menu somewhere, but it's far less important there since one wouid only be on those pages if you already have an account and are actively using it / logged-in to it).

Motivation

I'd like to get more people into decentralised social media, and encourage more people to follow sites they find interesting directly, without being limited to site run by big companies and/or those who maintain dedicated FB/birdsite accounts for those blogs.

For people in a transitional state where they are on board with news readers, it can make it easier to embrace and feel comfortable, I t hink, if they find that the microblogs they counter (public toots on Mastodon) can be followed this way as well. At least, until they're ready to commit to Mastodon fully 😄 (which has a fairly high barrier to entry through picking an instance, creating an identity, and then navigating the still fairly immature landscape of mobile apps). Especially compared to the well-established, localised and mature reader apps out there.

I'd be willing to help write a patch if this change is welcomed.

Would a patch be welcome for improving the RSS feed items as described?

See also https://github.com/tootsuite/mastodon/issues/14538

I'm encountering the same issue on polyglot.city (on masto.host), and observe it both when viewing a profile after searching for it, and after having followed them. I tried this in a web app (Pinafore), and in two mobile apps (Amaroq, and Tootle).

I was nearly sure this was a bug in one of the apps, until I realized that other apps suffer the same issue. I then thought it was a problem with Masto Host, but someone pointed me here, that it is in fact a more general issue that just happens to affect smaller instances the most.

Web	Amaroq app	Tootle app

I can sort of understand and explain to people around me, that replies and like/boost counts can be incomplete when looking at a specific toot, if that toot is from someone else, outside your local group.

However, I am unable to explain to people why it is that Mastodon lets them paste/search for any account, and click on accounts of boosted toots or comments, but then cannot "just" browse those account's profile and public toots. We let them click on it and show recent meta data, but then the profile contains only a handful of random/old toots. I think this might be negatively affecting adoption and growth among communities as it means accounts look unappealing or abandoned.

I don't know much about the inner workings of Mastodon. I can totally see how it might be infeasible to federate these ahead of time, and undesirable to locally federate these on-demand when the user isn't followed. But, that suggest to me a few things:

• Perhaps we should not consult the local database at all then when browsing a profile unless it is followed. Instead, use an upstream API query, possibly cached locally in some way. (Either naively, by query; or normalized into an efficient internal structure separate from the timeline data, with stronger cache expiry or something).
• Once a new account is followed, we either import "everything" (unlikely), or import just one toot and remember in some way the timestamp of their last public toot and/or when they were followed by non-zero accounts, and for any incomplete query crossing over that date, do the same as for unfollowed accounts.

I also note that we don't really promote web links to the public profile, and on mobile apps these links are often omitted from the interface entirely. I suppose an alternate solution could be to encourage apps to short-circuit links to non-followed accounts and have them point to public account URLs always (thus for apps, switching to a browser and removing the ability to easily follow them without resorting to separately logging in and/or tech-savvy gestures like copying URLs into clipboards), where some apps might choose to instead query upstream APIs directly from the client-side (which might be undesirable in terms of privacy and performance/caching/latency). If this direction is preferred, it might make sense to deprecate or otherwise emit a warning to apps when querying profile data for accounts that are not followed an known to be sparse/outdated.

See also:

• "proxy pagination" ref https://github.com/tootsuite/mastodon/issues/14023#issuecomment-689026176

@nolanlawson Is there something I can do as a next step toward this?

I'd also like to contribute a Dutch translation which in turn might make it easier to recommend Pinafore and Mastodon more generally toward my non-technical friends/family in the Netherlands.

Note that it gets worse, the rendering also continuously corrupts and uncorrupts while typing in an existing sequence of italic text. Whenever a new word gets added and a space is typed, it corrupts, and then uncorrupts once the next word has begun.

This makes the editor feel rather dizzy!

Similar to https://github.com/Automattic/simplenote-macos/issues/205

Reproduced

1. Create new note, Markdown is on by default.
2. Enter the following:

* ([Apple](https://books.apple.com)) _about how it was to work at Apple during the original development of Safari and later the iPhone, the internal social and technical processes

3. Add an underscore _ to the end. And observe rendering freak out.

Observed

Step 2	Step 3

Then, switch to another note and switch back. The renderer is now normal and with italic text. Then, remove the underscore. Observe that the renderer corrupts in this direction as well:

Step 2 (alt)	Step 3 (alt)

• MacBook Pro (Retina)
• macOS 10.15.6
• Simplenote 2.2

Apart from placing a button in the content, I'm not sure what the proposal offers over what (at least one) browser already provides? For instance, Safari UI already provides a share button by default on every page: […]

Similarly, sharing is built into mobile browsers like Safari:

@marcoscaceres wrote:

The API is specialized... using it to share the same page is kinda pointless.

Not if you're viewing a page in a progressive web app that is standalone or fullscreen. […]

👍 I too encounter this at times in offline/homescreen-supported PWAs where authors forget to put a share button in the interface, presumably because in the development stage one mainly tests in the browser mode where the address bar etc are all there.

Remove some of the indirection and simplify the way it works.

@step2yeung Friendly ping to check if you're able to find time for this. If not, I might give it a go next week for the next patch release. Thanks again!

@ventuno Absolutely! I wanted to understand if the timing and overall contract of afterEach would suit your needs. I agree we would need to make this much simpler indeed.

The way I've handled this in projects myself is by wrapping the test or module functions, like so:

const orgModule = QUnit.module;
let nested = false;
QUnit.module = function (name, executeNow) {
  if (nested || typeof executeNow !== 'function') {
    // Ignore nested modules, already inherits parent hooks.
    // Ignore non-scoped modules.
    return orgModule.apply(this, arguments);
  }
  const orgExecute = executeNow;
  executeNow = function (hooks) {
    hooks.beforeEach(function () {
      // Do global setup, e.g. sinon sandbox, app fixtures, etc.
    });
    hooks.afterEach(function () {
      // Do global teardown, e.g. restore sandbox, or assert zero open transactions.
    });
    nested = true;
    const ret = orgExecute.apply(this, arguments);
    nested = false;
    return ret;
  };
  return orgModule(name, executeNow);
};

This reduces the "hackiness" factor by a lot, but remains rather hacky still.

Perhaps an officially supported "global hook" would make sense. E.g. a way to implicitly add before, beforeEach, after, afterEach to all modules. That would also give you the future space for a "per suite" hook as you were hinting at.

In terms of ergonomics, I imagine it could work something like this:

QUnit.config.hooks.afterEach((assert) => {
 /* … */
});

If the project using QUnit has a local qunit.json file in the repository root, then the CLI was unable to find the 'qunit' package. Instead, it first found a local 'qunit.json' file.

This affected an ESLint plugin with a 'qunit' preset file.

This bug was fixed in Node 12, and thus only affects Node 10 for us.

The bug is also specific to require.resolve(). Regular use of require() was not affected and always correctly found the local package. (A local file would only be considered if the require started with dot-slash like ./qunit.)

Ref https://github.com/nodejs/node/issues/35367. Fixes https://github.com/qunitjs/qunit/issues/1484.

Tell us about your runtime:

• QUnit version: 2.11.2
• What environment are you running QUnit in? (e.g., browser, Node): Node

What are you trying to do?

Running qunit test/foo.js via npm test from package.json.

The project directory is a clone of https://github.com/wikimedia/eslint-config-wikimedia/.

What actually happened?

The QUnit CLI process fails early on due to confusing this file for the qunit package:

/eslint-config-wikimedia/node_modules/js-reporters/dist/js-reporters.js:1530
    runner.on('runStart', this.onRunStart.bind(this));
           ^

TypeError: runner.on is not a function
    at new TapReporter (/eslint-config-wikimedia/node_modules/js-reporters/dist/js-reporters.js:1530:12)
    at Function.init (/eslint-config-wikimedia/node_modules/js-reporters/dist/js-reporters.js:1598:14)
    at run (/eslint-config-wikimedia/node_modules/qunit/src/cli/run.js:45:19)
    at Object.<anonymous> (/eslint-config-wikimedia/node_modules/qunit/bin/qunit.js:56:2)

Manual inspection reveals that the runner variable received from https://github.com/qunitjs/qunit/blob/2.11.2/src/cli/require-qunit.js#L7 is in fact the qunit.json file, and not the qunit package.

		const localQUnitPath = resolve( "qunit", { paths: [ process.cwd() ] } );

https://hacktoberfest.digitalocean.com/faq

See https://hacktoberfest.digitalocean.com/faq.

There is no CRI event for individual assertions. Given we collapse tests by default in the interface, perhaps it's okay to lose this immediacy in the HTML DOM. Batching the DOM/layout to only happen at the end of each test might actually speed up execution as well.

The reporter currently uses testDone() which exposes the testId it uses to associate parts of the DOM, but callback doesn't expose the array of assertions.

The testEnd event, on the other hand, does have the assertion details, but doesn't have QUnit's testId.

I wrote more at https://github.com/qunitjs/qunit/issues/1118#issuecomment-702488633 about untangling testId from Core, for the benefit of plugins that change the HTML output.

I believe testId is probably something we only use in the HTML runner right now. On the CLI one wouldn't know that ID to pass even if we supported it there as argument. (The QUnit.config object is supported on Node, implicitly, which one could use from a boostrap file with --require, but that seems unusual, and something we'd breaking in QUnit 3.0 in favour of something better that we'd ship in QUnit 2.x.)

Thinking out loud:

• Perhaps QUnit.config.filter could support being a a callback function (or array of such), that QUnit gives an object similar to the testStart event data (test name, suite name, and full name).
• The HTML runner would use this to decide which tests should run, based on its query params. This could use the same hashing function we use today, or something else.

I'm looking into this as part of https://github.com/qunitjs/qunit/issues/1486, and running into an obstacle with testId. We currrently get this from Core and use it in the HTML reporter as part of the HTML element IDs, which are intended to be part of the public API (ref https://github.com/qunitjs/qunitjs.com/issues/159) so that QUnit plugins can use them to display additional visualisations.

For QUnit's own use, we could trivially generate a different set of IDs (e.g. lazily, from the testStart event).

For plugins, we may need to change it so that the plugin reacts to the HTML rather than influencing it from the inside. For example, the way a plugin finds the HTML element currently is via (contextual) assert.test.testId.

Straw-man proposal:

• HTML Reporter: Generate new test IDs here.
• HTML Reporter: Emit custom events (not part of js-reporters/CRI) for the purpose of augment the display of a completed test and a completed assertion. Analogous to QUnit.testDone (CRI testEnd) and QUnit.log (has no CRI event), from which we'd provide references to the DOM elements in question.

Challenges this brings about:

• Can we actually deprecate the core testId property? It seems we'd need to keep this at least privately for the URL parameter and re-running tests. However, "rerun" is an intimate part of the user interface. It's not like the checkboxes and module dropdown that are neatly separated in the would-be "HTML Runner" component.
• How would our HTML Reporter operate based on CRI events whilst still being able to do QUnit-specific things like re-running tests. Maybe it's fine to have inline conditionals that would be QUnit-specific and if it were to be its own project at some point, support for other custom features of individual testing frameworks could be added. Maybe that's not so bad, and still a good enough improvement over the status quo.

Perhaps it's not worth separating the two, but we could still add support for disabling the bulk of the output and running a plain text CRI reporter in its place. In any event, that could of course be a good first step either way.