autopkgtest fails in hirsute on armhf

Bug #1923090 reported by Balint Reczey on 2021-04-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
firefox (Ubuntu)
High
Olivier Tilloy

Bug Description

https://autopkgtest.ubuntu.com/packages/f/firefox/hirsute/armhf

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/armhf/f/firefox/20210408_154741_90187@/log.gz

...
autopkgtest [15:44:53]: test command3: [-----------------------
Traceback (most recent call last):
  File "/tmp/autopkgtest.D3W44g/build.bPt/src/debian/tests/search-engines", line 51, in <module>
search URL for Google: https://consent.google.com/ml?continue=https://www.google.com/search%3Fchannel%3Dfs%26client%3Dubuntu%26q%3Dfoobarbaz&gl=GB&m=1&pc=srp&hl=en&src=1
    assert url.netloc == v['netloc']
AssertionError
autopkgtest [15:45:08]: test command3: -----------------------]
autopkgtest [15:45:11]: test command3: - - - - - - - - - - results - - - - - - - - - -
command3 FAIL non-zero exit status 1
autopkgtest [15:45:12]: test command3: - - - - - - - - - - stderr - - - - - - - - - -
Traceback (most recent call last):
  File "/tmp/autopkgtest.D3W44g/build.bPt/src/debian/tests/search-engines", line 51, in <module>
    assert url.netloc == v['netloc']
AssertionError
...

Most likely an infrastructure proxy/networking error.

Balint Reczey (rbalint) on 2021-04-08
summary: - autopkgtest fails inhirsute on armhf
+ autopkgtest fails in hirsute on armhf
Olivier Tilloy (osomon) wrote :

Indeed this failure started happening on armhf recently (I'd say about a week ago or so) for all builds of firefox, affecting not just hirsute but also xenial, bionic, focal and groovy.

The google search URL that's printed suggests a race condition: selenium doesn't have a built-in method to wait until the current URL changes to a given value, instead it allows watching the URL until it changes from the current value. This combined with a slow test environment might explain why the google redirection (to their consent popup) happens before the real search URL is captured by the test.

Changed in firefox (Ubuntu):
status: New → Confirmed
assignee: nobody → Olivier Tilloy (osomon)
importance: Undecided → High
Olivier Tilloy (osomon) wrote :

I cannot reproduce the test failure locally, nor when running the test in an armhf LXC container on an arm64 cloud instance.

When running locally, I can see the google consent popup overlaid on top of the search results page, but the URL isn't rewritten, and the network tab of devtools doesn't show any query to consent.google.com either. There's definitely something different in the test environment that causes this bug.

Olivier Tilloy (osomon) wrote :

I am seeing the redirection when using firefox on android. It might be that Google uses the UA string to serve a mobile version of the consent page, and for some reason it thinks the UA string of the desktop version on armhf is that of a mobile device. Not sure why I'm not able to reproduce this in an armhf container though.

Olivier Tilloy (osomon) wrote :

This is the UA string of the desktop version on armhf:

    Mozilla/5.0 (X11; Ubuntu; Linux armv8l; rv:87.0) Gecko/20100101 Firefox/87.0

Olivier Tilloy (osomon) wrote :

But I'm still unable to reproduce the test failure on armhf.

Olivier Tilloy (osomon) wrote :

In the autopkgtest infrastructure, on armhf the UA string is:

    Mozilla/5.0 (X11; Ubuntu; Linux armv7l; rv:88.0) Gecko/20100101 Firefox/88.0

i.e. the difference with my tests in an armhf container is the architecture ("armv7l" vs "armv8l")

Olivier Tilloy (osomon) wrote :

And I can confirm that if I spoof the user agent using the "armv7l" token, the google search page is redirected to the consent page, which is consistent with what I'm seeing with firefox on android.

Olivier Tilloy (osomon) wrote :

That token in the UA string corresponds to the machine field of the result of the uname syscall (== `uname -m`).

Olivier Tilloy (osomon) wrote :
Changed in firefox (Ubuntu):
status: Confirmed → Fix Committed
Olivier Tilloy (osomon) wrote :

I built firefox with the fix above in a PPA and ran the autopkgtests in the official infrastructure, and I can confirm that they now pass on armhf.

The fix will be released with the next firefox stable update, version 88.0, due out next week.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 88.0+build2-0ubuntu0.20.10.1

---------------
firefox (88.0+build2-0ubuntu0.20.10.1) groovy; urgency=medium

  * New upstream release (88.0+build2)

  [ Olivier Tilloy ]
  * On armhf, override the UA string used by an autopkgtest to prevent Google
    from serving mobile content, which would break the test's expectations
    (LP: #1923090)
    - debian/tests/search-engines

  [ Rico Tzschichholz ]
  * Update cbindgen to 0.19.0
    - debian/build/create-tarball.py
  * Use clang 12 if available
    - debian/control{,.in}
    - debian/build/rules.mk
  * Update patches
    - debian/patches/rust-drop-dll-checksums.patch

 -- Olivier Tilloy <email address hidden> Fri, 16 Apr 2021 16:07:30 +0200

Changed in firefox (Ubuntu):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 88.0+build2-0ubuntu0.20.04.1

---------------
firefox (88.0+build2-0ubuntu0.20.04.1) focal; urgency=medium

  * New upstream release (88.0+build2)

  [ Olivier Tilloy ]
  * On armhf, override the UA string used by an autopkgtest to prevent Google
    from serving mobile content, which would break the test's expectations
    (LP: #1923090)
    - debian/tests/search-engines

  [ Rico Tzschichholz ]
  * Update cbindgen to 0.19.0
    - debian/build/create-tarball.py
  * Use clang 12 if available
    - debian/control{,.in}
    - debian/build/rules.mk
  * Update patches
    - debian/patches/rust-drop-dll-checksums.patch

 -- Olivier Tilloy <email address hidden> Fri, 16 Apr 2021 16:00:27 +0200

Changed in firefox (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers