I cannot browse the grammars in both PC and Mac, I get the following error. see below

[irina060981]

the problem with several extension attachment on iframe reloads

[irina060981]

Fixed

• update code to support iframe navigation catch
• update code to listen only for full page load

[monzug]

@irina060981 should I run an other regression test on FF too?

[irina060981]

All code is the same for Chrome and Firefox. So all changes here influnces to the same features in Firefox. So it is worth to test this functionality in Firefox too.

[monzug]

tested in FF/Mac in Alpheios Reading Tools 3.4.1 build incr-3.4.x.20211202255 Alpheios Components 3.3.3-incr-3.4.x.20211125318 build i331-la-lat-update-lang.20211201494

go to https://scaife.perseus.org/reader/urn:cts:latinLit:stoa0045.stoa002.perseus-lat2:1.1-1.5/ and double click on any word: e.g signant. you'll see two pop-up been generated before displaying the morphology pop-up. see below. also, the close icon (x) to close the pop-up works after few attempts. Note that from lookup or wordlist, I do not have this issue.

[monzug]

it works well in Chrome/Mac and PC. I was not longer able to reproduce the browsing issue.

[monzug]

I retested above issues in FF/PC in previous build and I confirmed that double click on signant does not produce 2 pop-ups before the morphology pop-up is generated, and that the x (close button) works well.

However in FF/PC in latest build, I could reproduce the same issues as reported in FF/MAC: double pop-up while browsing grammar, x button that does work only after several attempt, the double pop-up after double-clicking signant.

[monzug]

for the FF release, I suggested to use the previous build from yesterday.

[irina060981]

for the FF release, I suggested to use the previous build from yesterday.

I don't agree - it is from the main upgrade for FF release (move to the other event for removing permissions), if it has bugs in Chrome it could be in FF too, even if you don't see it. If to be honest I did a big change even if it doesn't seem this way from the outside.

And we should finish with it. Our extension is still available on Firefox, so we didn't over deadline yet.

So let finish with this upgrade with success and don't leave it in not safety state.

[irina060981]

ok, I think, I fixed it.

I could describe what is the main problem here.

When we could use big permissions as before , then we could have a simple event - page was reloaded, and attach any check, activation or other actions. And that's why in previous release there were decided to go this way.

Now when we could not use big permissions (and it is good because we don't really need them), we doesn't have access to this easy and clear event as "page is reloaded".

That's why I started to use the other event "tab was updated", and it has a lot of execution:

• different steps of page loading, different parts are loaded (like iframe) And also it could give very less information about the current execution.

So I needed to find a clear trigger (for both browsers) how to avoid multiple execution. Because we couldn't correctly understand - if extension parts are already attached from the code. All of these restrictions are sacrifices for increased security.

Why it is important to do it the same way for both browsers , because browser updates change these inner code without our participation. Because there aim to behave the same way for webextensions - but they are not at the finish. And this event - is an example when chrome and firfox tells us not exactly the same information on tab update. But it could be changed in any future (near or far).

Finally I attached to the following tab update - favicon full upload. Every site has only one favicon. Iframe doesn't have favicon. So when a user reloads a page with previously activated extension - and when favicon is loaded and sent to onTabUpdated this information - we attached the extension.

From my tests everything works correctly. I tested in both browsers. It is equal for both browsers so it is a big chance that it won't change in near future.

The only exception could be here (that I could imagine) - a site doesn't have favicon at all, it is a rare situation (I don't know such sites). But anyway - then a user would need to activate extension himself manually and that's all.

Hope, @monzug , this is the final fix. If everything is ok - I could send our final extension to FF today or tomorrow (Saturday) after your tests.

[monzug]

let's cross fingers. will start soon then.

On Fri, Dec 3, 2021 at 6:38 AM Sklyarova Irina @.***> wrote:

Assigned #342 https://github.com/alpheios-project/webextension/issues/342 to @monzug https://github.com/monzug.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/alpheios-project/webextension/issues/342#event-5710027073, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ32UOOHSWH65K57O3G2HR3UPBJWPANCNFSM5JGNBCIQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[monzug]

@irina060981 - installed latest build in FF/MAC. just noticed something about scrolling bars of the grammar that needs more testing and to compare with previous build. Anyhow I clicked on log in, then cancel the log in. the message on the bottom still says: wait while we are logging you in, at this point I closed the pop-up and the alpheios app closed too. by clicking on it, the icon became active but no toolbar available and a bunch of errors in the log related to favicon

I clear the log of browser error and activate alpheios icon again. still no toolbar. this is the error in the log

[monzug]

I am not able to replicate the problem of the tools that do not show up on reactivation. really need to find a reproducible scenario. anyhow on canceling login I get the following errors:

[irina060981]

Most of published errors are not ours.

And others say that some Auth remote services are not available.

[irina060981]

And grammar scrolling is not from my code - if it is reproduced - it is from our old code.

[irina060981]

I tried to log in through Firefox - and could do it without any errors

[monzug]

Excellent. glad to hear that. I am more concerned about the tools that not shows up on reactivation.

[monzug]

I tried to log in through Firefox - and could do it without any errors

yes,login works. when you get to the login page and cancel login then you get the errors. and this is the error that I get on alpheios activation with no tools available:

[irina060981]

I am glad that login works. I belive that there could be some not clear behaviour - because Auth0 changed somehow. That's it is important to spend time for authentication for FF and Chrome when we will have time.

[irina060981]

It is not our error it is from the site where you are.

If you try on the other site - you won't see this error

[monzug]

found the reproducible scenario of tools not available (latin library and scaife) or toolbar not longer functioning in https://www.tradurreantico.it/latino/grammatica-latina/morfologia/verbo/verbo-eo-latino/ activate tools, browse grammar, reload page. in scaife and latin library the tools are not longer available. turn on and off and on, alpheios toolbar does not show up.

[monzug]

also on loebclassics, on reload tools are not longer available. no error in the browser console.

[monzug]

to recap: 1) yesterday's build Alpheios Reading Tools 3.4.1 build incr-3.4.x.20211202255Alpheios Components 3.3.3-incr-3.4.x.20211125318 build i331-la-lat-update-lang.20211201494 chrome/PC: latin library, scaife - reload page, Alpheios toolbar does not show up FF/PC:  scaife: on reload page, tools are generated -   in the latinlibrary, on reload toolbar is there, but browse inflection tables, grammar, user account and options are not clickable. when I click on it, it does not do anything. if I reload again all works. Basically it works on second reload (I have to say that I noticed that before but as soon as I reloaded the page, it worked so I did not pay any attention). chrome/mac: scaife, latin library on reload tools do not show up. 2) latest build Alpheios Reading Tools 3.4.1 build incr-3.4.x.20211203162 Alpheios Components 3.3.3-incr-3.4.x.20211125318 build i331-la-lat-update-lang.20211201494 FF/MAC: on reload tools are not longer available (multiple sites) Chrome/MAC: latinlibrary, on reload tools are not longer available. However Loebclassics works well, also on reload.

with latest build in FF, the reload of page is definitely an issue. The FF build has deteriorated compare with the build in which I performed the regression test.

[irina060981]

ok - I have no new thoughts how to do this detection the same for Chrome and Firefox. I would need more time for investigation how to solve this problem on Chrome (to handle with removed permissions).

I am not sure if I have this time - then let's rollback to the release that was successfully tested for Firefox and send it for publishing.

It is very sad that we don't have time to work with it in a normal flow - without hurry and compromisses.

[irina060981]

I returned the condition that we had on verified release. Do small checking on the following sites:

http://www.thelatinlibrary.com/quintilian/quintilian.institutio9.shtml https://www.loebclassics.com/view/aelian-characteristics_animals/1958/pb_LCL446.9.xml?rskey=8fxQje&result=2 https://scaife.perseus.org/reader/urn:cts:latinLit:stoa0045.stoa002.perseus-lat2:1.1-1.5/

• double click on the page
• double click from the wordlist
• grammar navigation
• page reload
• leave page without actions and the lookup/reload

I didn't see any multiple attachment