Haven’t seen this since upgrading to 18.04, and can’t reproduce it following the instructions anymore either, so it appears to be fixed.

Impacted version: 0.60

Server Setup Information:

• Operating System: Ubuntu 16.04
• Deployment Method: snap
• ROOT_URL environment variable (Is there a subfolder?): https://my-domain.com/kan (yes)

Problem description:
A description consisting entirely of a URL that happens to extend from the left edge to the right edge of the description field makes it impossible to edit the description, as clicking anywhere on the viewer lands the click on the URL, which triggers a new browser tab instead of the editor.

Here’s a screenshot of such a URL overlapping the editing area, as highlighted by the inspector in Firefox.

There’s actually a couple of pixels worth of unlinked, clickable editor area at the right edge here, but you need a really steady hand and mouse to hit those pixels.

A workaround seems to be to change the browser zoom level (either way), causing the URL to extend either over to the next line or properly short of the right edge of the first line (turning the rest of the line clickable).

After upgrading to Quantum, the right mouse button context menu for HTML links pops up in the wrong place when the Firefox window is pushed to either side of my screen (so that the window takes up half of the horizontal space). The issue appears similar to what has been reported in bug #1721614 (particularly as it appears in the video attached by the submitter), but for me the issue does not occur with the hamburger menu or other UI elements, only with links on webpages, and the menu highlighting behavior is different: in my issue the highlighting occurs normally only once I point the cursor at the menu.

== Steps to reproduce ==
1. Create a new profile and start Firefox using the profile.
2. Expand the window to fill the screen (if not already).
3. Enter search terms into the URL bar and hit enter to bring up a search results page.
4. Right-click a search result title to bring up the context menu. Left-click outside it to close it.
5. Grab the window title bar and push the window to the right edge of screen to resize the window to span half of screen horizontally. Release the title bar.
4. Right click the search result title again.

== What happens ==
The menu pops up on way off from where the mouse cursor is. See attached screenshot.

== What should happen ==
The context menu should pop up next to mouse cursor.

== Possible culprit ==
This seems to be somehow tied to localization: if I uninstall firefox-locale-*, then create a new Firefox profile, with this new profile the menu pops up where it should. I’m using Finnish locale, but this is reproducible with just firefox-local-en too, although the mispositioning differs between locales (Finnish pushes the menu off to the left, whereas English pushes it down and to the right).

== Workaround ==
Don’t right-click on the page before resizing the window (that is, skip step #4 above). This seems to be the trigger.

== Other info ==
I’m able reproduce this in a (16.04) VM just as well as on the host desktop.

In case the collected data doesn’t include this, my primary display is 2560 × 1440p, and the only display connected. xrandr output:

Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 8192 x 8192
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 connected primary 2560×1440+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
2560×1440 59.95*+
2048×1152 59.90
1920×1200 59.88
1920×1080 60.00 50.00 59.94 24.00 23.98
1920x1080i 60.00 50.00 59.94
1600×1200 60.00
1680×1050 59.95
1280×1024 75.02 60.02
1280×800 59.81
1152×864 75.00
1280×720 60.00 50.00 59.94
1024×768 75.03 60.00
800×600 75.00 60.32
720×576 50.00
720×480 60.00 59.94
640×480 75.00 60.00 59.94
720×400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)
HDMI-3 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)

Screenshot with the context menu off to the left of mouse cursor (Finnish locale) Edit (490.3 KiB, image/png)

Sivuston uudistuksen myötä etusivulla nyt olevien uutis-, ilmoitus- ja kuulutusotsikkolinkkien toiminnassa on jotain kummallista. Seuraavassa kuvailemani ongelma ilmenee välillä, välillä taas ei.

Jos valitsen esim. ”Omaishoidontuen ohjeet muuttuvat 1.5.2017 alkaen” -otsikon oikealla hiirennapilla, ja valitsen kontekstivalikon ”Avaa uuteen välilehteen” -toiminnon, uuteen välilehteen avautuu etusivu, ei linkattu artikkeli. Bugi ilmenee myös, jos kopioin artikkelin linkin leikepöydälle (saman kontekstivalikon kautta) ja liimaan sitten tuon kopioidun osoitteen toisen välilehden osoitepalkkiin (välilehdellä avautuu artikkelin sijasta etusivu). Tämä hankaloittaa artikkeleiden jakamista.

Suoraan vasemmalla hiirennapilla avattuina linkit tuntuisivat toimivan kuten odottaisinkin (samalla välilehdellä avautuu siis otsikkoon linkitetty artikkeli).

Onnistuin toisintamaan bugin Firefoxilla (53.0) ja Chromella (58.0.3029.81), mutta tosiaan vain hetkittäin; välillä linkit toimivat myös kontekstivalikon kautta kuten pitääkin, eli otsikkoon linkitetty osoite viittaa artikkeliin eikä etusivulle.

I prefer to use anchors closest to the point when communicating links. Unfortunately on many websites those anchors are hard to pick up using basic browser features. Typically, you’ll have to dig into the page source and manually copy the element id you want.

This add-on does that for you. That’s all it does, and for such specific use the no-frills approach is perfect.

As a bonus, the developer is friendly and issues can be easily raised through Github. (Not that such a simple tool should have many, but the one I had was fixed in no time.)

Just tested it and I can confirm that it works. Thanks a lot! I’ll post a review on AMO right after this.

I’m using Firefox 41.0 (in Ubuntu 14.04). Steps to reproduce:

1. Go to Firefox privacy settings, set ”Remember history” (allow FF to restart if needed)
2. Install jump to anchor
3. Verify it works (context menu has ”Jump to anchor”)
4. Go to Firefox privacy settings, set ”Never remember history” and allow FF to restart
5. Open context menu

What happens:
”Jump to anchor” is missing from the context menu.

Hi Christopher, sure. For the test user, I just go to the top right cog menu, select ”Startup Applications…” and ”Add” Firefox (/usr/bin/firefox). Firefox remembers the window size, so I start it once (manually), maximize the window and then close it. On the next login, it should start maximized.

Steps to reproduce:
0. Set up Chromium/Firefox to prompt when it’s not the default browser (e.g. for FF, set browser.shell.checkDefaultBrowser to true)
1. Create/save a file with .html extension
2. From Nautilus, open the file’s properties
3. On the Open With tab, select gedit as default application to open html files with
4. In System settings, select Details and verify that in Default Applications the Default Web Browser hasn’t changed
5. Start Chromium/Firefox

What happens:
The browser thinks it’s not the default browser anymore and prompts you to set it as such.

What I expect to happen:
For the browser to know it still is the default browser and not ask about it.

Has this happened before:
Doesn’t seem to apply to Lucid, so the bug occurs somewhere between 10.04…12.04.

Further info:
I’ll attach a screenshot demonstrating the above result.

I’m not at all sure whether I filed this against the right package, feel free to correct it.

This is apparently caused by something not in Chromium itself: it’s not reproducible in a VM running Oneiric, with 17.0.963.26 from ppa:chromium-daily/dev nor with Chrome 17.0.96356. It *is* reproducible in Precise with the latter too, but not reproducible with Firefox nor Epiphany. In Precise with Chromium 17, it’s reproducible with a temporary profile and a guest login also.