Created attachment 8945361 [details] Screenshot from ING_nl.png User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180123171915 Steps to reproduce: 1. Select Screenshot Tool right from the Awesome Bar. 2. Click the area to grab. Actual results: The moment the squared area is clicked, on the right a white space appears from top to bottom. This white space is approx. 1/5 of the full screen width. Because of the white space the selection region jumps to the left. The visible offset is actually not the area that is grabbed, since it grabs the location you clicked initially on, also if you adjust the selected region size. Expected results: There shouldn't appear white space on the right. The selection region shouldn't relocate and the offset shouldn't be there.
This seems the occur at the ING.nl website, at other sites it is not happening.
I've tried to see if the problem reproduces with ing.ro, where I have a homebank account as well, but the sites are different, so no luck with that. Benoit, could you please confirm that this problem wasn't reproducible on FF57? And if it is not could you please assist further by doing a mozregression? - hopefully this will point us at the bug that introduced this issue, although my gut feeling says it's more of a web compatibility issue. Here is the mozregression link: http://mozilla.github.io/mozregression/documentation/usage.html and you will probably want to use mozregression --good 57 --bad 58 I do realize that it's going to be a bit troublesome, having to login to your ing account several times, but IMO this is the fastest way to identify if the culprit here is just a site compatibility issue or something more serious.
I don't want to downgrade to FF 57 so I have no idea to test it on FF 57 under Linux Mint. Is there a portable version available? So I installed the 'mozregression' tool and ran it like you advised. It asks for results on FF 59, which seems strange since I needed to test between FF 57 & 58. This is the output: $ ~ mozregression --good 57 --bad 58 0:00.08 INFO: Using date 2017-11-13 for release 58 0:00.08 INFO: Using date 2017-09-21 for release 57 0:03.95 INFO: Testing good and bad builds to ensure that they are really good and bad... 0:03.95 INFO: Downloading build from: https://archive.mozilla.org/pub/firefox/nightly/2017/09/2017-09-21-22-02-43-mozilla-central/firefox-58.0a1.en-US.linux-x86_64.tar.bz2 ===== Downloaded 100% ===== 0:16.50 INFO: Running mozilla-central build for 2017-09-21 0:29.25 INFO: Launching /tmp/tmpfEX5aC/firefox/firefox 0:29.25 INFO: Application command: /tmp/tmpfEX5aC/firefox/firefox -profile /tmp/tmpzMz2Uj.mozrunner 0:29.25 INFO: application_buildid: 20170921220243 0:29.25 INFO: application_changeset: ca7d18dbacbf103d74a3213d8d08a7c3e4def9a2 0:29.25 INFO: application_name: Firefox 0:29.25 INFO: application_repository: https://hg.mozilla.org/mozilla-central 0:29.25 INFO: application_version: 58.0a1 Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good 2:30.12 INFO: Using local file: /home/benoit/.mozilla/mozregression/persist/2017-11-13--mozilla-central--firefox-59.0a1.en-US.linux-x86_64.tar.bz2 (downloaded in background) 2:30.12 INFO: Running mozilla-central build for 2017-11-13 2:42.82 INFO: Launching /tmp/tmpMpmY7k/firefox/firefox 2:42.82 INFO: Application command: /tmp/tmpMpmY7k/firefox/firefox -profile /tmp/tmpFaQ0FC.mozrunner 2:42.82 INFO: application_buildid: 20171113220112 2:42.82 INFO: application_changeset: c616a6fd5e4b20cca139fcdd3957682afaa862b9 2:42.82 INFO: application_name: Firefox 2:42.82 INFO: application_repository: https://hg.mozilla.org/mozilla-central 2:42.82 INFO: application_version: 59.0a1 Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry' or 'exit' and press Enter): good 3:57.76 ERROR: Build was expected to be bad! The initial good/bad range seems incorrect. I hope you or someone else can use this...
Benoit, that makes sense in a way. To better understand, 58 release version today has been at some point 58 beta and 58 nightly, so when you input as parameters --good 57 --bad 58, it extracted the dates and run the bisection on Nightly channel between the two identified dates. But apparently, both builds returned good (a bad was expected in order to get a result), which means that the regression wasn't there. That's a bit weird. Could you please try manually downloading/extracting and running Firefox 57.0.4 from here: http://ftp.mozilla.org/pub/firefox/releases/57.0.4/linux-x86_64/en-US/ You can extract it in a different location and remove it after testing, so it doesn't affect your current version.
Hi Adrian, I tested it with 57.0.4 and the problem is not present in this version. I just tested it again in 58.0 and there I see the same issue occurring. It seems to be present in the latest stable version only. Is there more I can do to support you?
Thanks Benoit for all the time spent supporting this. It would be helpful to have a public access site that can reproduce this problem, so if you can spot the same problem on a public site, please add that info here. Meanwhile, we'll move this bug to the Screenshot component, to see if there's any clue based on 57-58 changes as to why this might happen.
status-firefox58: --- → affected
status-firefox59: --- → ?
status-firefox60: --- → ?
Component: Untriaged → Screenshots
Keywords: regression, regressionwindow-wanted
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
This issue sounds very similar with bug: https://github.com/mozilla-services/screenshots/issues/3907 However, the issue is fixed in the latest Screenshtos 28.0.0 dev version and will land in the next release. @Benoit can you please retest this in latest Nightly (60.0a1) build with latest Screenshots dev version to confirm if the issues is no longer reproducible? You can install the Screenshots dev version by following the steps from here: https://screenshots.dev.mozaws.net/homepage/install-test-local.html You can download the latest Nightly build from here: https://ftp.mozilla.org/pub/firefox/nightly/2018/02/2018-02-03-22-03-31-mozilla-central/firefox-60.0a1.en-US.linux-x86_64.tar.bz2
@Adrian: I will look for a public accessible site hving this problem. This might take some days... @Cosmin: Interesting! I will retest the issue in the latest Nightly with the latest Screenshots dev version. That will be at least on Wednesday, I have no time I am afraid. Will come back to this!
Benoit, please start with Cosmin's retest request(comment 7). If that returns positive results, meaning if it is not reproducible anymore on Firefox Nightly (60.0a1) with latest Screenshots dev version, then the public access site is not required anymore. I'll add the NI flag back to you, remove it once you manage to re-test. Thanks for the time invested in helping out.
status-firefox58: affected → wontfix
status-firefox59: ? → fix-optional
@Adrian & @Cosmin: I tested it how Cosmin told me to and the issue I encountered is gone! I tested multiple manners, areas of screenshots and different pages and could not reproduce the issue on the locations I had it before. I used the Nightly version from yesterday: https://ftp.mozilla.org/pub/firefox/nightly/2018/02/2018-02-07-10-03-55-mozilla-central/firefox-60.0a1.en-US.linux-x86_64.tar.bz2 Screenshots was version 28.0.0 (Build date February 01, 2018 23:32:12 UTC, commit 28.0.0-268-gc5fde637). Thanks for your support helping me test this issue. Glad it is solved! Regards, Benoit
@Benoit Thanks for testing this! So, it seems that the issue is fixed in the latest Screenshots version by: https://github.com/mozilla-services/screenshots/issues/3907 The new version of Screenshots (29.0.0) will be released next week in latest Nightly. Considering this I will close this issue as Resolved-Worksforme.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 days ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.