Closed Bug 1500375 Opened 6 years ago Closed 6 years ago

[remote-dbg-next] migrate aboutdebugging test: browser_addons_debug_webextension.js

Categories

(DevTools :: about:debugging, enhancement, P1)

enhancement

Tracking

(firefox67 fixed)

RESOLVED FIXED
Firefox 67
Tracking Status
firefox67 --- fixed

People

(Reporter: jdescottes, Assigned: jdescottes)

References

(Blocks 2 open bugs)

Details

(Whiteboard: old-remote-debugging-ng-m3)

Attachments

(6 files)

filter on remote-debugging-next-move-m3-to-m2
filter on remote-debugging-next-move-m3-to-m2
filter on remote-debugging-next-move-m3-to-m2
No longer blocks: remote-debugging-ng-m3
Priority: P3 → P2
Whiteboard: old-remote-debugging-ng-m3

You can have a look at the following documentation for some tips on how to migrate tests: https://gist.github.com/juliandescottes/fecc426ac84600357259bf513cea744c

Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
Priority: P2 → P1

Small refactor that will be useful for the upcoming patches were we install
temporary extensions from existing XPI files

Depends on D17053 . Just renaming and moving the helper for consistency

Depends on D17054

The previous version only relied on a manifest, but it's not really flexible.
The XPI approach allows to define background scripts, which can be useful for
more tests.

Note: the old about:debugging supports both the manifest and the XPI approaches
but we should try to keep only one here to make it less complicated to write new
tests.

Depends on D17055

Added console to the name, otherwise a straightforward migration normally.

Depends on D17056

We started migrating the about:debugging tests to the new about:debugging folder.
I guess we should still apply the webextensions tag to them?

Depends on D17055
Sadly on Windows loading a temporary addon as an XPI will lock the file.
This means we cannot update the addon during the test and we cannot test
the reload feature on windows.

The only other solution I can see is to add again the alternate API using
the TemporaryExtension helper to install an "exploded" temporary extension.
I would really like to avoid that, I feel like it's already complicated to
know which method to use in order to install extensions, between temporary
extensions, regular extensions, file based extensions... I would like to
avoid adding yet another method just for one test.

Let me know what you think.

Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ce48248ceaf8 Support path or file when installing temporary addon in test;r=daisuke,Ola https://hg.mozilla.org/integration/autoland/rev/17f82957f62c Rename installRegularAddon to installRegularExtension;r=daisuke,Ola https://hg.mozilla.org/integration/autoland/rev/1b45bc69411d Switch to XPI based helper to install fake extensions;r=daisuke,Ola https://hg.mozilla.org/integration/autoland/rev/2b7b8078a63a Skip addon temporary buttons test on Windows;r=daisuke,Ola https://hg.mozilla.org/integration/autoland/rev/c1bcc87a8c68 Migrate browser_addons_debug_webextension.js to new about:debugging;r=daisuke,Ola https://hg.mozilla.org/integration/autoland/rev/4935a429a2b7 Add webextensions tag to migrated extensions debug tests;r=rpl
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: