Bugzilla

I was able to run the wpt test [enabled-by-permission-policy-attribute-redirect-on-load.https.sub.html](https://searchfox.org/mozilla-central/rev/5a7e5e2e1fe04028fc77787084caf9b26ab74ce6/testing/web-platform/tests/geolocation/enabled-by-permission-policy-attribute-redirect-on-load.https.sub.html) locally by forcing wpt to rebuild its manifest once.  (Command line args didn't work for this but inserting `_kwargs["rebuild"]=True` [here](https://searchfox.org/mozilla-central/rev/5a7e5e2e1fe04028fc77787084caf9b26ab74ce6/testing/web-platform/manifestupdate.py#80) did.  Additionally, the system clock has to be set before Sept 11 2024 to avoid an invalid cert.)  With that, I see the same behavior as for the recent m-c with `geo.prompt.open_system_prefs=false` -- it presents the permissions dialog and then times-out waiting for a response.  The test results are a "timeout" and a "didn't run".

@saschanaz, bug 1902720 removed `geo.prompt.testing=true` when you added the mock location server.  It also fixed a bunch of expected timeouts -- those timeouts resemble the ones I'm seeing now (even before the Windows UI work in bug 1900225).  So, before bug 1902720, we had those prefs and were timing out anyway -- the exact opposite of what I would have expected.  Then, you removed those prefs and apparently the timeouts went away -- again, the exact opposite of what I'd have expected given my results here.  Do you have any insight into this?  I would just re-add the two prefs from comment 7 and be done with it but the history has me doubting my conclusions.  The real question I have is whether the policy stuff is supposed to test that the permission dialog isn't shown (I'm thinking no?) or if it is really just intended to be used to *deny* geolocation access (so you still get the dialog even with an explicit allow permission)?

I was able to run the wpt test [enabled-by-permission-policy-attribute-redirect-on-load.https.sub.html](https://searchfox.org/mozilla-central/rev/5a7e5e2e1fe04028fc77787084caf9b26ab74ce6/testing/web-platform/tests/geolocation/enabled-by-permission-policy-attribute-redirect-on-load.https.sub.html) locally, using m-c from before bug 1900225 landed, by forcing wpt to rebuild its manifest once.  (Command line args didn't work for this but inserting `_kwargs["rebuild"]=True` [here](https://searchfox.org/mozilla-central/rev/5a7e5e2e1fe04028fc77787084caf9b26ab74ce6/testing/web-platform/manifestupdate.py#80) did.  Additionally, the system clock has to be set before Sept 11 2024 to avoid an invalid cert.)  With that, I see the same behavior as for the recent m-c with `geo.prompt.open_system_prefs=false` -- it presents the permissions dialog and then times-out waiting for a response.  The test results are a "timeout" and a "didn't run".

@saschanaz, bug 1902720 removed `geo.prompt.testing=true` when you added the mock location server.  It also fixed a bunch of expected timeouts -- those timeouts resemble the ones I'm seeing now (even before the Windows UI work in bug 1900225).  So, before bug 1902720, we had those prefs and were timing out anyway -- the exact opposite of what I would have expected.  Then, you removed those prefs and apparently the timeouts went away -- again, the exact opposite of what I'd have expected given my results here.  Do you have any insight into this?  I would just re-add the two prefs from comment 7 and be done with it but the history has me doubting my conclusions.  The real question I have is whether the policy stuff is supposed to test that the permission dialog isn't shown (I'm thinking no?) or if it is really just intended to be used to *deny* geolocation access (so you still get the dialog even with an explicit allow permission)?