Anca/ User can pinned extensions on the sidebar

[soncuteanca]

Bugzilla: 2010283
TestRail: 2652535

Description of Code / Doc Changes

• Add User can pinned extensions on the sidebar test
• Add several methods in sidebar BOM
• The Sidebar area is not an easy one to access, reliable only via JS.

Process Changes Required

Mark the relevant boxes, delete irrelevant lines.

• Adds a dependency (rerun pipenv install)
• Modifies a git hook (rerun ./devsetup.sh)
• Changes the BasePage
• Changes or creates a BOM/POM (name the object model): _
• Changes CI flow
• Changes scheduled Beta or DevEdition
• Changes Git hooks or Github settings
• Changes L10n harness

Screenshots or Explanations

If you need to explain your code, do it here.

Comments or Future Work

Do we need to start another PR soon to address something you saw while working on this?

Workflow Checklist

• Reviewers have been requested.
• Code has been linted and formatted.
• If this is an unblocker, a message has been posted to #dte-automation in Slack.

Thank you!

[github-actions]

Good work navigating the shadow DOM complexity here. The JS-based approach and explanatory docstrings are appreciated.

Three things to address:

1. Unused JSON entries (sidebar.components.json): The three new entries (customize-sidebar-button, sidebar-extension-item, manage-extensions-link) are dead code — the BOM methods use JS directly and never read from the manifest. Remove them or wire them up.

2. Wrong POM used in test (line 33): about_addons.click_on(add-to-firefox) is called while the AMO web page is active, not about:addons. The element should live in a manifest for the AMO page (or generic_page) and be accessed via page.click_on(...).

3. Inconsistent wait timeout: expect_extension_pinned_to_sidebar uses a 30s custom wait; the other two methods use the default. Align them or document the reason for the difference.

[github-actions]

Good work navigating the shadow DOM complexity here — the JS-based approach with inline attribute checks is well-reasoned and the docstrings explain the GeckoDriver limitation clearly.

A few issues to address:

1. Unused variable and import — about_addons = AboutAddons(driver) is instantiated but never used. The AboutAddons import can be removed as well.

2. Missing element_clickable before click_on("add-to-firefox") — The rest of the test waits for clickability before clicking (e.g. lines 35–36), but the initial install button click doesn't. This risks a StaleElementReferenceException if the AMO page is still loading.

3. Missing wait_for_num_windows before switch_to_new_tab — click_manage_extensions returns as soon as the JS click fires, but the new tab may not yet be in driver.window_handles. Other tests (e.g. test_hyperlink_context_menu.py) call tabs.wait_for_num_windows(2) before switching. The same pattern should be applied here.

[ben-c-at-moz]

LGTM...can you do a demo sometime for the team on how you figure out the JavaScript you need to execute here?