Opened 22 months ago

Last modified 3 months ago

#6276 accepted defect

Hiding the context menu button breaks the Tools->HTTPS Everywhere menu

Reported by: grarpamp Owned by: pde
Priority: normal Milestone:
Component: EFF-HTTPS Everywhere Version: HTTPS-E 4.0dev8
Keywords: Cc: swrobel, EisahLee@…
Actual Points: Parent ID:
Points:

Description

When you drag the httpse icon from the urlbar to
'menu_bar.view.toolbars.customize' window you lose the
'menu_bar.tools.https_everywhere' drop down menu content for httpse,
though the menu item itself is still there. At that point, the only
way to configure httpse is via 'about:addons'. Or of course to
restore the icon to the urlbar.

Seems to me the drop down menu content should remain regardless of
where the icon is, or is not.

FF 10.0.3 ESR
HTTPS-E v2.1

Child Tickets

TicketSummaryOwner
#6035Empty 'Tools->HTTPS Everywhere' menu in Firefoxpde

Change History (8)

comment:1 Changed 21 months ago by pde

  • Component changed from HTTPS Everywhere: Chrome to EFF-HTTPS Everywhere
  • Summary changed from HTTPS-E: loss of toolbar menu via icon location to [CHROME] HTTPS-E: loss of toolbar menu via icon location

comment:2 Changed 20 months ago by pde

  • Status changed from new to accepted
  • Summary changed from [CHROME] HTTPS-E: loss of toolbar menu via icon location to Hiding the context menu button breaks the Tools->HTTPS Everywhere menu

comment:3 Changed 20 months ago by pde

This is a super-weird XUL bug; thanks for noticing it. If there's an easy fix I'll implement it, but no promises.

In the mean time, a workaround is to drag the context menu button into the "Addons bar" which is at the bottom of the screen. You can hide the addons bar, and the Tools->HTTPS Everywhere menu will still function.

comment:4 Changed 20 months ago by pde

A few debugging notes:

  • This bug doesn't seem to happen in 2.2.1?
  • This error looks possibly causal/related:

Error TypeError: popup is null [x-] in file chrome://https-everywhere/content/toolbar_button.js, line 45, character 0.

  • Even though this bug sort of appears to have been introduced since the 2.x branch, I can't yet see any super-suspicious commits that predate this bug report but postdate the 2.x/3.0development divergence.

comment:5 Changed 20 months ago by pde

Hrm, now I can reproduce in 2.2.1. That makes a lot more sense.

comment:6 Changed 9 months ago by swrobel

  • Cc swrobel added
  • Milestone set to HTTPS-E 4.0dev9
  • Version set to HTTPS-E 4.0dev8

Still exists in 4.0dev9

comment:7 Changed 3 months ago by pde

  • Cc EisahLee@… added
  • Milestone HTTPS-E 4.0dev9 deleted

I started work on this bug in the toolbarbuttonless branch of my remote. But this is not a high priority because it affects so few users and could certainly use some help from people who care about it.

comment:8 Changed 3 months ago by pde

Currently the code in my toolbarbuttonless branch is at minimum broken because the l10n / require logic for translating strings in JavaScript requires the addons SDK to be working, and it isn't in our codebase yet.

So working out how to do translations with pure XPCOM would be the next step.

Note: See TracTickets for help on using tickets.