Browser extension/share sheet input bug [spec-ed]

pirijan · January 1, 2024, 6:01pm

RE “I noticed that there is an issue were the URL isn’t always correctly posted to the input field.”

affected repos

kinopio-club/kinopio-client/blob/main/src/views/Add.vue

<script setup>
import { reactive, computed, onMounted, onUnmounted, onBeforeUnmount, defineProps, defineEmits, watch, ref, nextTick } from 'vue'
import { useStore } from 'vuex'

import inboxSpace from '@/data/inbox.json'
import Loader from '@/components/Loader.vue'
import User from '@/components/User.vue'
import ResultsFilter from '@/components/ResultsFilter.vue'
import utils from '@/utils.js'
import cache from '@/cache.js'
import consts from '@/consts.js'
import postMessage from '@/postMessage.js'

import { nanoid } from 'nanoid'
const store = useStore()

const state = reactive({
  email: '',
  password: '',
  loading: {

This file has been truncated. show original

Issue

This is is a race-condition bug in the /add page which affects all browser extensions and the iOS share sheet. When the /add page view is mounted, window.addEventListener('message', insertUrl) is created which listens for postMessages to populate the default value of the input field.

In theory, when the browser extension window, or the share sheet is open, it’ll send an input value via a postmessage. But the input still appears empty

Possible cause

the /add page is reloaded or updated to load the current kinopio user. This process refreshes or clears the input.

Possible resolution

If that’s the cause, is there a more reliable, non-time/event based method that the parent browser and ios share extension can send a message to the iframe?

e.g. maybe by setting a default navigator value or some other global that can be read and set by the /add page whenever it’s ready? The transmission mechanism should ideally be supported by iframes both in a browser extension context and app.

Ship updates for

the /add page,
browser-extensions for all platforms (see readme: firefox and chrome are almost the same, and there’s steps for building the safari from the firefox one). There are also instructions on how to submit to each app store, and i’ll send you the credentials for that or just update the repo and i can do that part
ios app,
and ‘Add to Kinopio’ mac safari extension app (see readme in browser-extensions) will need to be updated

lucas · January 2, 2024, 12:20am

I think if the problem is that the /add page is reloaded or updated, we would have to store the URL in localStorage so it survives a reload.

From the app side of things, that wouldn’t be an issue. AFAIK this should also work for iFrames because they have access to the local storage of their domain.

pirijan · January 2, 2024, 2:27am

Ya that sounds like a good approach. I can take care of that soon so you can focus on other stuff

swap · January 2, 2024, 10:06am

Is this related to the issue from this screenshot? The input field with the URL (or free text) is empty when I share to Kinopio on iOS.

(white/gray rectangle is me censoring private parts, not an issue )

pirijan · January 2, 2024, 12:50pm

Yup same issue

pirijan · January 3, 2024, 3:30am

fix for this is now live and tested (as browser-extension). The initial textarea value should be a lot more reliable now

lucas · January 4, 2024, 1:19am

Is there something we have to change for the iOS share sheet?

pirijan · January 4, 2024, 1:30am

i don’t think so , I also didn’t have to update any of the browser extensions. I think now we could remove that 500ms delay you added tho