1673085 - analytics.google.com - double scrollbars prevent scrolling

Status: RESOLVED WORKSFORME

(Core :: Layout: Scrolling and Overflow, defect, P2)

Description

[Francesco]

Attachment: firefox82_wrong.png

On analytics.google.com, open a report (possibly one with enough data to display) and change some option such as the type of report (data, performance etc.) or the number of rows to show.

FF 82 displays an additional vertical scrollbar (see the attached screenshot) and makes it effectively impossible to scroll down. Reloading the page temporarily fixes this, until you change some option again. This did not happen in FF 81.

The reports are in an iframe (id #galaxyIframe) and the problem seems related to sizing this element. Its width and height, set by inline styles, are right when interacting with the main document (for instance, opening a report through the left menu), but wrong (since FF 82) when interacting with the embedded document (for instance, changing the number of rows).

Comment 1

[Francesco]

Attachment: firefox81_right.png

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I don't have anything to repro, but I'll ask around. Is there any chance you could test a build from https://nightly.mozilla.org and see if it works on Nightly already?

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Ok, so I got access to some analytics... I couldn't reproduce the issue off-hand, though I'm on Linux so it might be due to some difference in scrollbar sizes or something.

Comment 4

[Francesco]

I tried today in another box, this bug does not reproduce on win10 x64.

It does reproduce on (my) win7 x86. Only thing: when I tried in a blank profile, at first it did not reproduce, so I thought of some issue with my profile. However, I tried again in the blank profile and it did reproduce. Then, I downloaded FF 82.0.2 portable and set up a separate installation. Again, it did not reproduce at first, it reproduced in following attempts.

I think this need be tried on some other Win7 box.

Comment 5

[Carlo Cannas]

I can confirm Firefox 82 and Firefox 83 on Linux are also affected by this.
As Franceso, I started experiencing this issue after updating to Firefox 82. Today I updated to Firefox 83 hoping it would also fix this annoying problem, but it's still there.
I can reproduce it fairly frequently while navigating in an Analytics report: it could happen basically every time the report reloads after any change of the view. For example it may happen after: searching, changing date interval, changing ordering of a table or changing the number of rows displayed - as already mentioned by Francesco.

I'm using the official Debian package: http://deb.debian.org/debian/pool/main/f/firefox/firefox_83.0-1_amd64.deb

Please let me know if I could provide more information to help addressing this issue.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

If you can reproduce on debian, running mozregression --good 81 --bad 82 and posting the result here would be immensely helpful, see the docs for more info, and let me know if you get stuck or need any help.

Comment 7

[Francesco]

(In reply to cannas carlo from comment #5)

I can confirm Firefox 82 and Firefox 83 on Linux are also affected by this.
As Franceso, I started experiencing this issue after updating to Firefox 82. Today I updated to Firefox 83 hoping it would also fix this annoying problem, but it's still there.
I can reproduce it fairly frequently while navigating in an Analytics report: it could happen basically every time the report reloads after any change of the view. For example it may happen after: searching, changing date interval, changing ordering of a table or changing the number of rows displayed - as already mentioned by Francesco.

I'm using the official Debian package: http://deb.debian.org/debian/pool/main/f/firefox/firefox_83.0-1_amd64.deb

Please let me know if I could provide more information to help addressing this issue.

If you can reproduce on Linux amd64 then my comment #4 "this bug does not reproduce on win10 x64" is probably wrong. I don't have access to that box right now, but I likely didn't try enough times. As I said in comment #4, this bug seems not to reproduce on the very first try.

Comment 8

[Francesco]

I downloaded and (Firefox virus warning notwithstanding...) run mozregression-gui. The log says:

Bug 1589102 - Part 17: Don't set chrome context in Marionette reftest unit tests r=marionette-reviewers,whimboo
Differential Revision: https://phabricator.services.mozilla.com/D88518

Hope I operated the tool correctly and this helps.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Yeah! That sounds like a weird regressor for a layout issue, but maybe it caused a timing issue or such... Would be curious if the regression range for comment 5 is the same.

Comment 10

[Francesco]

While running mozregression I noticed that, if you try hard enough, the bug is reproducible also in Firefox 81. What happened is that, for some reason, the bug became much more prevalent and easier to reproduce in Firefox 82. I considered as bad for regression purposes the first build where that happens.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Thanks, that's really helpful info.

That seems like it could be caused by bug 1589102 which changes the timing of about:blank and about:srcdoc.

At this point I suspect something odd is going on with what google is doing on that page... Anny, ni? just in case you can repro and take a closer look...

Karl, is there any chance we could try to contact the GA folks to see if they can poke?

Comment 12

[Carlo Cannas]

Attachment: regression.log

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

If you can reproduce on debian, running mozregression --good 81 --bad 82 and posting the result here would be immensely helpful, see the docs for more info, and let me know if you get stuck or need any help.

Oh, I didn't know such tool existed. For a moment I thought it would do a complete build at each step, but i see it just downloads pre-compiled nightly builds. Nice!

I had to expand the bisect range since I was able to easily reproduce the issue on the very first step and it told me
Build was expected to be good! The initial good/bad range seems incorrect.

In the end it found this: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8fad18d87c946b2652d9284b91e5fb2424266d2f&tochange=8396d94496e0a24c3edfb4a4862d14ddb8528396
Could it make sense?
I'm attaching the full log.

I'll look to run it again, just to be sure I end up with the same result.

To me it seems to be some timing issue like a race condition. I even tried to debug it using the devtools but the scripts used in the page are really big and Firefox ends up using a lot of memory and gets killed by OOM.
I think we might try to report the issue to Google using the "Send feedback" feature (the button next to your Google account photo in any Analytics page).

Comment 13

[Karl Dubost💡 :karlcow]

Contacted Google on the partner mailing list.

Comment 14

[Anny Gakhokidze [:annyG]]

Not clearing the NI yet, but I wasn't able to reproduce this neither on my mac nor my windows 10 VM. I also don't have any information in my GA account, because I signed up for a fresh account and I am not subscribed to any services.

Emilio, should I ask someone to get me access for a GA account that has more data, so I can see if this reproduces or wait to look into it until Google responds since :karlcow is contacting them?

Comment 15

[Carlo Cannas]

Hi Anny,
if you need access to a Google Analytics property you can use the demo one: https://support.google.com/analytics/answer/6367342?hl=en

Comment 16

[Emilio Cobos Álvarez (:emilio)]

I don't have a good sense of how responsive Google folks are generally for these things... But trying to repro with comment 15 sounds promising. cannas, can you reproduce the issue on that link?

Comment 17

[Anny Gakhokidze [:annyG]]

Thank you, cannas! I used the demo account on my Mac and Windows 10 VM machine, but was still unable to reproduce it in 81 nor 82, nor latest nightly.

Comment 18

[dm.regger]

I've got the same issue a month ago or earlier. This is not the case in Google Chrome.

Window 7 SP1, 64-bit
Firefox 83.0, 64-bit
Chrome 87.0.4280.88, 64-bit

Comment 19

[Yulia Startsev [:yulia]]

I spoke with Matt Hobbs on twitter about this issue: https://twitter.com/TheRealNooshu/status/1346079793318670338

FF 84.0.1
Steps:
• GA --> Audience --> Tech --> Browser & OS
• Sort one of the columns to acceding / descending (sessions seen in the screenshot).
• Double scrollbar seen to the right, can no longer scroll on the page. Lower data can no longer be seen. https://pic.twitter.com/qTGvLwTXzf

I can also reproduce it, using the steps he outlined, on 85.01a. I tested on chrome canary and safari as well. Only firefox had the issue in my case, running on macOS if it helps.

Comment 20

[Timothy Nikkel (:tnikkel)]

I'm able to reproduce on macos but only if my system scrollbar settings are "Automatically based on mouse or trackpad", ie disappearing scrollbars. If I'm in always show scrollbar mode (so that scrollbars take up layout space) then the problem doesn't happen.

When I toggle the ascending/descending it also toggles the problem for me. I observed that the containing iframe has an inline style set for the height and toggling the ascending/descending toggles it between 1307px and 645px. With 1307px the problem happens, 645px it does not.

Loading the same page in Chrome I see that there is a scrollbar type object that is always visible and takes up layout space even though my system setting is for disappearing scrollbars, so it is likely a scrollbar implemented in content. When I toggle ascending/descending the height of the same iframe does not change.

So we are getting a different version of the page for Firefox.

Comment 21

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi, as per comment 12, is it ok to remove the regression window wanted keyword and mark "has reggression range" yes?
Thanks!
Clara

Comment 22

[Emilio Cobos Álvarez (:emilio)]

Yes. I couldn't verify bug 1649965 was actually the culprit though...

Comment 23

[Anny Gakhokidze [:annyG]]

Following STR above, I was able to reproduce this bug on my mac and using mozregression noticed it's happening even on Aug 1, 2020 (my patches landed on Aug 29, 2020) - unable to scroll down albeit without the second scroll bars appearing as they do in screenshots. I haven't gone all the way back to track when the bug first started occurring, even though it starts being more reproducible at the end of August. Given that this is in layout code and was happening even before my changes, I'm going to leave this for the layout team.

Comment 24

[Francesco]

As of today, March 5, I can no longer reproduce this bug. This doesn't seem related to a change in Firefox, since I upgraded to 86 last week and the bug was still reproducible even yesterday. It may have been a change by Google. Are others still able to reproduce?

Comment 25

[dm.regger]

This issue is no longer reproduced by me too. Windows 7 x64, Firefox 86.0 (64-bit).

Comment 26

[Daniel Holbert [:dholbert]]

Cool, let's call this WORKSFORME then. Thanks!