| Time |
Nick |
Message |
| 02:26 |
|
sleary joined #evergreen |
| 07:31 |
|
collum joined #evergreen |
| 07:40 |
|
kworstell-isl joined #evergreen |
| 08:00 |
|
BDorsey joined #evergreen |
| 08:01 |
|
redavis joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:07 |
|
dguarrac joined #evergreen |
| 10:24 |
|
akilsdonk joined #evergreen |
| 10:33 |
|
jvwoolf joined #evergreen |
| 10:51 |
|
sandbergja joined #evergreen |
| 10:59 |
sandbergja |
Good morning! Announcing sleary, terranm, and I are starting up the collaborative code review sessions again on Monday. Please join if you'd like to share knowledge, see how others are solving Evergreen bugs, and move pull requests forward. Details are on the community calendar. Would love to see you there! |
| 11:05 |
jeff |
excellent news! |
| 11:37 |
Bmagic |
can you setup more than one <module> for Added content? |
| 11:39 |
jeff |
not currently. often discussed. |
| 11:40 |
jeff |
(may be some very rare exeptions for that mix of certain providers in certain ways, but even then probably not without code/template level changes) |
| 11:40 |
Bmagic |
jeff++ |
| 11:41 |
Bmagic |
I see Amazon.pm is available, though not mentioned in the documentation. Is that depricated? |
| 11:42 |
jeff |
I would not use it. I don't know that we've deprecated it in any way other than (it seems) omitting it from mention in docs. |
| 11:42 |
Bmagic |
seems that it only works for images, though that might* satisfy the library asking |
| 11:42 |
jeff |
I don't know that there's a current way to make it work without violating usage terms. |
| 11:42 |
jeff |
YMMV (or s/mileage/opinion/) |
| 11:43 |
Bmagic |
oh, licensing, well then I don't want to touch it |
| 11:43 |
berick |
it burnses |
| 11:44 |
jeff |
I have seen ASINs in 020 before, because "then the right image loads". |
| 11:44 |
jeff |
(I am also not recommending this) |
| 11:45 |
Bmagic |
I won't mention Amazon :) |
| 11:46 |
jeff |
Haven't narrowed this down much yet, but about to open a bug: Chrome (possibly just in the last month or two) seems to be preventing a new background tab from accessing Hatch. From /eg2/en-US/staff/splash, control-clicking the Home icon results in a background tab that has no workstation, and loads the register workstation page. Reloading the page fixes it (but at that point you're still on the register |
| 11:47 |
jeff |
workstation page). |
| 11:47 |
jeff |
similar to (but not exactly) bug 1967532 and bug 2044033 |
| 11:47 |
pinesol |
Launchpad bug 1967532 in Evergreen "Opening browser client from desktop link sometimes fails to connect to Hatch" [Undecided,New] https://launchpad.net/bugs/1967532 |
| 11:47 |
pinesol |
Launchpad bug 2044033 in Evergreen "Make Evergreen resilient in the face of Chrome's prefetching and prerendering" [Undecided,Confirmed] https://launchpad.net/bugs/2044033 |
| 11:48 |
jeff |
turning off prefetching doesn't seem to help. wondering if it's closer to power/memory management changes. |
| 11:48 |
berick |
cannot reproduce w/ 120.0.6099.199 on linux |
| 11:48 |
jeff |
using Hatch? |
| 11:48 |
berick |
yeah |
| 11:49 |
* Dyrcona |
mumbles something about editors and indentation being adjusted automagically. |
| 11:50 |
jeff |
In the newly opened tab, before reloading the page, window.document.documentElement.getAttribute("hatch-is-open") returns null. |
| 11:51 |
jeff |
reloading the page causes it to return the expected value. |
| 11:51 |
jeff |
(and workstation fetching from Hatch works, as evidenced by the workstation appearing in the top nav) |
| 11:52 |
jeff |
might be something Windows-only. I've tested on 2+ machines running Windows 10 with Hatch 0.3.3 |
| 11:53 |
jeff |
Evergreen 3.10 and 3.12. I can reproduce on demo.evergreencatalog.com |
| 11:53 |
jeff |
Haven't tried to reproduce on Linux or macOS, mostly because we don't use Hatch on those anywhere currently. |
| 11:58 |
jeff |
interesting. it also happens when I right-click and "Open link in new window". That new window opens in the foreground, so that seems to rule out something related to background tabs or page visibility api. |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:09 |
jeff |
no report in console of the new window/tab loading the Hatch relay content script. |
| 12:23 |
|
kworstell-isl joined #evergreen |
| 12:35 |
jeff |
If anyone else has a Windows machine with Chrome and Hatch and wants to confirm that they can reproduce (or not!), please do. :-) |
| 12:35 |
jeff |
bug in progress. |
| 12:40 |
dguarrac |
jeff: We also have the same problem. Windows + Chrome + Hatch. We only started encountering this after upgrading to 3.11 from 3.7. I could have sworn that I had reported this bug after our upgrade in November, but I don't see it in my list of reported bugs. |
| 12:42 |
jeff |
so far for me, it only happens when opening Home in a new tab or window from an /eg2/ page. I don't know if that's because other /eg2/ pages take more time to load and eliminate some race, or if there's something specific about the way Angular does nav links that's coming into play. |
| 12:42 |
jeff |
dguarrac++ glad (I think) to hear it's not just us. |
| 12:43 |
jeff |
I'll link the bug here when done. |
| 12:46 |
dguarrac |
jeff++ thanks! |
| 12:59 |
mmorgan |
jeff: I'm seeing this also. I open new backgroud tabs from menu items all the time, but never the home/splash screen, so haven't noticed this before. |
| 13:15 |
Stompro |
Jeff, we see it also. EG 3.11 + Hatch + chrome 120.0.6099.224 |
| 13:15 |
|
kworstell-isl joined #evergreen |
| 13:15 |
Stompro |
On winders |
| 13:16 |
mmorgan |
We're on 3.10 fwiw |
| 13:18 |
Stompro |
If I change the link to /eg2/en-US/staff/splash from /eg2/en-US/staff then it works fine opening it in a new tab. |
| 13:18 |
Stompro |
#fixedit |
| 13:19 |
Dyrcona |
"And there was much rejoicing." |
| 13:20 |
jeff |
yeah, I was playing around with that and trying to understand the significance. :-) |
| 13:24 |
* mmorgan |
was also :) |
| 13:25 |
mmorgan |
even /eg2/en-US/staff/ works fine. It just doesn't without the final / |
| 13:31 |
jeff |
ah, I wonder... |
| 13:34 |
Dyrcona |
The rewrite thingy? Is that what you wonder? |
| 13:37 |
jeff |
I think it comes down to the extension manifest matches, and hitting /eg/staff gives you an HTTP redirect but /eg2/staff gets you a 200 OK and all further navigation is the Angular router and pushstate/whatnot. |
| 13:37 |
jeff |
the extension manifest only matches: "matches": ["https://*/eg/staff/*", "https://*/eg2/*/staff/*"] |
| 13:37 |
jeff |
so Chrome never tries to load the Hatch extension on that page. It's unrelated to "open in new tab" or "open in new window", that's just how we found it. |
| 13:38 |
jeff |
locale-less especially doesn't match. |
| 13:40 |
Dyrcona |
So, add the location to the manifest? |
| 13:44 |
jeff |
but again the locale-less gets an http redirect (307), which is then cached. |
| 13:49 |
jeff |
maybe, or add the redirect. I think I favor the latter, but it's probably time to finish writing it up and make a branch. :-) |
| 13:49 |
jeff |
berick++ dguarrac++ mmorgan++ Stompro++ Dyrcona++ |
| 13:50 |
jeff |
berick: I'm now a little more curious why you aren't seeing it on Linux, though. |
| 13:51 |
jeff |
on Windows in Chrome with Hatch installed/enabled, I can break it by logging in, then trying to go to https://example.com/eg2/en-US/staff -- even just pasting that into a fresh tab. |
| 13:52 |
jeff |
(where "break it" is: no workstation name after the username in the top right corner; redirected to the register workstation page) |
| 13:53 |
|
dguarrac joined #evergreen |
| 13:55 |
Stompro |
jeff++ thanks for tracking this down |
| 13:58 |
jeff |
things that this seems to have had nothing to do with: background tabs, preloading/prefetch, memory/energy saving, angular routing, Chrome updates, and field tests. :-) |
| 14:12 |
berick |
jeff: hm, turns out I can reproduce in main, but not in KCLS-tweaked EG 3.9 |
| 14:12 |
* berick |
tries 3.11 |
| 14:15 |
jeff |
reproduced on Debian 11 with Chrome Stable against 3.12 (demo.evergreencatalog.com) just now. |
| 14:16 |
berick |
hm, kcls-3.11 works as expected as well |
| 14:16 |
|
dguarrac joined #evergreen |
| 14:18 |
jeff |
what status code do you get with curl -I https://example.com/eg2/en-US/staff (replacing example.com with your hostname)? |
| 14:19 |
berick |
oh, what Stompro said |
| 14:19 |
berick |
the link goes to /eg2/en-US/staff/splash in our code |
| 14:19 |
jeff |
yeah, that'll do it. |
| 14:22 |
berick |
jeff: your comment about the manifest explains it, right? we just need to change the link |
| 14:22 |
berick |
confirmed the /staff/ also works OK |
| 14:22 |
berick |
s/the/that/ |
| 14:23 |
jeff |
yeah. I'm thinking belt && suspenders: change link(s), add redirect in Apache. |
| 14:23 |
berick |
+1 |
| 14:23 |
jeff |
if an HTTP redirect causes the change in URL, we're good. if the Angular router does it, it's not good enough / too late. |
| 14:24 |
berick |
yeah |
| 14:34 |
Dyrcona |
Working on Aspen reminds me of batch days when you'd have programs queued up to run on the mainframe overnight, and you wouldn't find out if it worked or not until the next day. :) |
| 14:50 |
|
kworstell_isl joined #evergreen |
| 14:52 |
|
kmlussier joined #evergreen |
| 14:56 |
|
jihpringle joined #evergreen |
| 14:58 |
collum |
Dyrcona - I just had a TAP flashback (Transaction Assurance Processing) |
| 15:00 |
|
kworstell-isl joined #evergreen |
| 15:01 |
Dyrcona |
collum++ |
| 16:06 |
Dyrcona |
hm... We should drop pg 10 and pg 11 from prerequisites. |
| 17:04 |
|
jvwoolf left #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 18:33 |
|
book` joined #evergreen |
| 18:52 |
|
kmlussier left #evergreen |
| 19:04 |
|
sandbergja joined #evergreen |
| 19:16 |
|
Christineb joined #evergreen |
| 20:01 |
|
sandbergja joined #evergreen |
