New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MTNI-199 ⁃ Checklist for finishing up releasable product. #1
Comments
so, now that @poltak hustled through and replaced the search TWICE, we are on the finish line! The last things to do are: FeaturesPRIO 1:
PRIO 2:
Bugs
|
@poltak Weird search times: |
@oliversauter Need a bit more details about the first one. Is it reproducible at all and with different types of search? If on the search branch, make sure to reinstall the ext from scratch and wipe your data whenever you update as well. RE listed bugs:
This is the expected behaviour of the WebExt API. If the user closes a tab while it's extracting tab data, it will crash as the tab won't exist anymore in memory.
We currently store the full res PNG screenshot. We could change to JPEG format and specify to the WebExt API to capture them at lower quality. Relevant API. We only use these as thumbnails for the Overview UI right now, so we can easily get them down to ~50Kb with lower quality JPEGs, but depends if you have any future plans (like displaying them larger somewhere).
It should still be there, it's just below the results. Either we can stop rendering the results list view immediately as a new query is detected (just leaving the spinner), or we can move the spinner somewhere, like overlaying on top of the results list.
This one already fixed in my new search branch. Will come later.
In the results list? For pages that don't have favicon data, it should not render any image element there. Can you give me a URL of a page where I could reproduce this behaviour and see if I can fix it? |
My wonder was here at first, why the total search time was so high, even though the term search time was rather low. My assumption is that the gap of about 3000ms came from loading all those documents from pouch. It was especially impactful for terms that appear in many pages.
What storage-size would be reasonable so we could display them a bit larger, maybe 3-4 times the size of right now?
Why not removing the previous results, if a search is made, so the regular spinner is on top again?
I saw it a couple of times with twitter pages.
Should we maybe then delete the page completely? |
With the first one, need to be able to reproduce it first or else everything is just speculation. Will see if I can try get it reproducible with larger data set later today.
All depends on the amount of visual artefacts you want visible. That would be the main result of changing to JPEG and lowering quality. I'll try a few quality values later and send you some screenshots of what it would look like.
Really need specific examples of where it's happening for you so I can reproduce.
Yeah, it would be nice, but as the entire page visit scenario is a bunch of async stuff, there's no guarantee of what stage it got up to before the user cancelled the tab (the state of the DBs, both for index and pouch, is unknown). This one would be better as its own issue to work towards and see how we can handle different scenarios. |
Hack: looked for terms in DB that have 300+ urls in the map.
I figured it is for twitter pages that I import, where this problem appears.
Ok defo something for later. |
This one would be a bit messy to implement. We'd either need to do:
Open to other suggestions.
Anything logged to console should only really be a concern to devs; shouldn't really need to concern ourselves with standard users opening the console - they can if they want. At the moment it should be mostly timers for various events and various errors that are caught. None are needed at all, but the errors are nicer than hiding them, IMO. Any ideas with what you want/don't want in there? |
Ok, was just an idea. Let's do it later. I think it is a good onboarding feature. But defo for later improvement
In the old extension I often got the feedback that in the console of a page (not the extension console) it was cluttered with (error) messages, thus being annoying for developers who use the console to investigate other things unrelated to the extension. So prio would be to remove all logs that appear on the page logs. I currently only see 1 though: |
- this stuff gets run in content script, hence pollutes every page's console that it runs on - #1 (comment)
THANK YOU all for your awesome work in the past months. You made this possible. Closing this as all things for the release have been done. |
These are the things that still need to be done in order to make the upgraded WebMemex extension releasable:
Want to back this issue? ?utm_campaign=plugin&utm_content=tracker%2F59103681&utm_medium=issues&utm_source=github Post a bounty on it! We accept bounties via ?utm_campaign=plugin&utm_content=tracker%2F59103681&utm_medium=issues&utm_source=github Bountysource.
The text was updated successfully, but these errors were encountered: