[remote-dbg-next] Reloading about:debugging on a remote runtime page should remain on the same page

VERIFIED FIXED in Firefox 68

Status

enhancement
P1
normal
VERIFIED FIXED
6 months ago
10 days ago

People

(Reporter: jdescottes, Assigned: jdescottes)

Tracking

(Blocks 1 bug)

unspecified
Firefox 68
Dependency tree / graph

Firefox Tracking Flags

(firefox68 verified, firefox69 verified)

Details

(Whiteboard: [remote-debugging-reserve])

Attachments

(1 attachment)

Assignee

Description

6 months ago
STRs:
- open new about:debugging
- connect to a remote device
- reload about:debugging

ER: User should remain on the remote runtime page
AR: Redirected to this-firefox

We now persist connections across reloads, so we should be able to stay connected. Note this might have slightly regressed since we aggressively try to stop ADB whenever we don't use it.
Assignee

Updated

6 months ago
Priority: -- → P3
Assignee

Comment 1

4 months ago

Depends on Bug 1528912 to keep connection on USB runtimes when reloading.

Depends on: 1528912
Assignee

Updated

2 months ago
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
Priority: P3 → P1
Whiteboard: [remote-debugging-reserve]
Assignee

Comment 2

2 months ago

The idea is to wait for ADB runtimes to be available before trying to render the initial route.
This way if we happen to find the runtime matching the current runtime, and if we still have a connected client for it, we can display the same runtime page.

Comment 3

2 months ago
Pushed by jdescottes@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d93d203fad60
Remain on the same Runtime page when reloading about:debugging r=ladybenko,daisuke

Comment 4

2 months ago
bugherder
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
Flags: qe-verify+
QA Contact: hani.yacoub

Comment 5

18 days ago

Verified as fixed on Firefox Nightly 69.0a1 and on Firefox 68.0b5 on Windows 10 x 64, Mac OS X 10.14 and on Ubuntu 18.04 x64.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

Comment 6

18 days ago

Actually I observed now that when I was connecting via USB, and after reloading "about:debugging" page, I was Redirected to this-firefox.
Is this the expected behavior in thins case?

Flags: needinfo?(jdescottes)
Assignee

Comment 7

18 days ago

(In reply to Hani Yacoub from comment #6)

Actually I observed now that when I was connecting via USB, and after reloading "about:debugging" page, I was Redirected to this-firefox.
Is this the expected behavior in thins case?

No it should remain on the same page (unless you are killing the ADB process for instance). Can you share more details about your test scenario?

Flags: needinfo?(jdescottes) → needinfo?(hani.yacoub)

Comment 8

13 days ago
  1. open new about:debugging.
  2. Make sure that you are connected to a network location.
  3. Enable USB Device.
  4. Connect to a mobile device. At this point you are connected via USB and via Network location.
  5. Make sure that the run time of the mobile device is selected.
  6. Reload about:debugging (it might need to reload the page 2-3 times)
Flags: needinfo?(hani.yacoub)

Comment 9

11 days ago

Julian, did you have the time to look into this? Should I log a bug separate bug for this?

Flags: needinfo?(jdescottes)

Sorry I missed your update!

Thanks for the additional info. Unfortunately I can't reproduce this for now, even reloading about:debugging very quickly a dozen of times I always remain on the runtime page for my mobile browser.

The STRs are specific enough to go into a separate bug. Since I can't reproduce this bug for now, I think we will need all the information possible (eg which mobile browser, which OS, etc). And if you can open the browser toolbox, to see if any error is logged when about:debugging fails to remain on the correct page, it would be useful as well.

Thanks!

Flags: needinfo?(jdescottes)

Comment 11

11 days ago

Sure, I will add all the information needed in detail in a separate bug.
Thank you!

Comment 12

10 days ago

Logged bug 1557308.

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