Open Bug 1673085 Opened 1 month ago Updated 4 days ago

analytics.google.com - double scrollbars prevent scrolling

Categories

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

Firefox 82
x86
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: vertova, Unassigned, NeedInfo)

References

(Regression)

Details

(Keywords: regression, regressionwindow-wanted)

Attachments

(3 files)

Attached image 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).

Attached image firefox81_right.png
Component: General → Layout: Scrolling and Overflow
Product: Firefox → Core

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?

Severity: -- → S2
Flags: needinfo?(vertova)
Priority: -- → P2

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.

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.

Flags: needinfo?(vertova)
QA Whiteboard: [qa-regression-triage]

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 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.

(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.

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.

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.

Regressed by: 1589102

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.

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?

Flags: needinfo?(kdubost)
Flags: needinfo?(agakhokidze)
Attached file 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).

Flags: needinfo?(kdubost)
Summary: Firefox 82 breaks analytics.google.com → analytics.google.com - double scrollbars prevent scrolling

Contacted Google on the partner mailing list.

You need to log in before you can comment on or make changes to this bug.