1461988 - The Side View pop up is blank for a brief moment when the toolbar button is clicked multiple times, after sending links from the "nytimes.com" website to the sidebar

Status: RESOLVED WONTFIX

(WebExtensions :: Frontend, defect)

Description

[Cristina Badescu [:cbadescu], Experiments QA]

Attachment: SV - white pop up.gif

[Notes]:
- On Mac, this issue is easier to be encountered if you send a link from "nytimes.com" page to the sidebar, click quickly the toolbar button multiple times and then send another link and click the toolbar button again.
- I've encountered this issue only for the links sent from the "nytimes.com" website, but there could be more websites like this that can cause this behavior.

[Affected versions]:
- Nightly 62.0a1
- Side View 0.4.3

[Affected Platforms]:
- All Windows
- All Mac
- All Linux

[Prerequisites]:
- Have a clean Firefox profile with the latest Side View version 0.4.3 (custom built on 2018-05-16) installed.

[Steps to reproduce]:
1. Open the Firefox browser with the profile from prerequisites.
2. Navigate to "https://www.nytimes.com".
3. Right click an article title and select the "Open link in sidebar" option.
4. Rapidly click the toolbar button multiple times.
5. Repeat Steps 3 & 4 with different articles and observe the behavior.

[Expected result]:
- Each time the Side View pop up is correctly opened and closed.

[Actual result]:
- The Side View pop up is blank for a brief moment and afterwards it is populated.

[Regression]:
I've managed to find a regression-windows using the Mozregression tool. Here are the results:
Last good revision: 8d070df4285e4eb45015ad5023bb220088d62af5
First bad revision: ad3d005f6a3683d095095fcb22dc875b07318a2b
Pushlog: https://goo.gl/25P2kN
From the pushlog, it seems that bug 1414245 has caused this issue.

[Additional notes]:
- Sometimes, the "Current" and "Recent Tabs" appear for a brief moment, but they are not populated.
- This issue is easy to be noticed if Dark Theme is enabled.
- The Side View experiment can be downloaded from the GitHub repository: https://github.com/mozilla/side-view.
- Attached is a screen screen recording with this issue.

Comment 1

[Cristina Badescu [:cbadescu], Experiments QA]

Shane, can you please take a look at this issue and see what might have caused it?
Thanks.

Comment 2

[Shane Caraveo (:mixedpuppy)]

This is not an extension feature, rather it is a browser feature, and one that will get removed (though that is low priority).

Comment 3

[Shane Caraveo (:mixedpuppy)]

Further note.  I cant see how the listed regression is possible, none of that code is even touched for bookmark/web panel sidebars.

Comment 4

[Cristina Badescu [:cbadescu], Experiments QA]

Actually, Side View is a webextension sidebar and not a bookmark/panel sidebar.

Comment 5

[Shane Caraveo (:mixedpuppy)]

Ah, I scanned the STR and this:

3. Right click an article title and select the "Open link in sidebar" option.
4. Rapidly click the toolbar button multiple times.

That read like a bookmark in the toolbar opening a sidebar link.


What toolbar button are you referring too that you click on?  The sidebar button that closes/opens the sidebar?  A browserAction button?

Is the behavior noticed in regular use, or only when forced by the rapid clicking of the button?

Is the perceived delay loading the article in the sidebar any different than loading the article in a tab?

Comment 6

[Shane Caraveo (:mixedpuppy)]

Hrm, video.  Sorry, still digesting coffee.

All the referenced regression patch does is place the sidebar into the extension process which only should have any affect if we ever turn on more than one process for extensions.

There's a couple things going on in there and it's hard to tell what is really going on.  However, loading a webpage in a sidebar browser should take a similar amount of time as loading it into a tab.  So I'm not sure there's anything that can really be done here.

Comment 7

[Andrew Swan [:aswan]]

This should be reported to the Side View developers first, if they can isolate it to an issue with a specific webextension API or feature then we can take a look.

Comment 8

[Cristina Badescu [:cbadescu], Experiments QA]

Sure thing. This issue is also filed here: https://github.com/mozilla/side-view/issues/254. I'll come back with updates as soon as I got them.
Thanks.

Comment 9

[Shane Caraveo (:mixedpuppy)]

For the browserAction, I don't see how the delay can be related to the sidebar, it does not appear to be interacting with the sidebar on opening of the panel.  I think rather it is doing some dynamic generation of html that is waiting on async functions.  It would appear faster if there were a default view (which could be rendered fast) that the lists were then inserted into as available.  It is also using synchronous localStorage to fetch the cached tabs it renders when it first opens.

I would probably suggest some redesign of the extension so it has a fast initial display and avoids localstorage.

Comment 10

[David Durst [:ddurst]]

I'm going to close this since it's being tracked in the correct repo (https://github.com/mozilla/side-view/issues/254). Carrying tracking flag with this redirect, and noting that the WONTFIX is the WebExtensions: Frontend.

If this turns out to be on us rather than Side View, we'll reopen.

Comment 11

[Mike Taylor [:miketaylr]]

Thanks David.

(we're supposed to have a RESOLVED→MOVED resolution... but maybe that's not enabled for Toolkit product)

Comment 12

[Andrew Swan [:aswan]]

:miketaylr did you mean to reopen this?

Comment 13

[Mike Taylor [:miketaylr]]

(Erm, no. Sorry)