Closed Bug 1940533 Opened 2 months ago Closed 2 months ago

controls on web pages no longer work with latest update. Right mouse, open link in new tab does not work. How do I roll back to previous version?

Categories

(Firefox :: Search, defect, P1)

Product:
Firefox
Component:
Search
Version:
Firefox 134
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
136 Branch
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox134 + verified
firefox135 + fixed
firefox136 + fixed

People

(Reporter: wooden35, Assigned: mbeier)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [sng])

Attachments

(4 files, 1 obsolete file)

Broken search.json.mozlz4
3.30 KB, application/octet-stream
Details
Bug 1940533 - Fix search settings v11 migration fail when going back and forth between releases. r?standard8
48 bytes, text/x-phabricator-request
Details | Review
Bug 1940533 - Fix search settings v11 migration fail when going back and forth between releases. r?standard8
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-beta+
Details | Review
Bug 1940533 - Fix search settings v11 migration fail when going back and forth between releases. a=RyanVM
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-release+
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

Any right mouse click, opens different longer list of options, and no option works properly. Cannot open link in new tab and stay in current tab, especially in mail.yahoo.com

Actual results:

nothing happens, no tab opens. Have to click on link which takes me to new tab, and then click back to yahoo.mail.

Expected results:

new tab opens, stay in current tab with yahoo mail.

The most likely cause is CSS customizations (via userChrome.css) or extensions that break your menu. Similar report here, with no answers from the reporters: https://www.reddit.com/r/firefox/comments/1hw67w5/firefox_update_broke_right_click_menu/

Are you using userChrome.css?

Does it work if you start Firefox in Troubleshoot mode?

Flags: needinfo?(wooden35)

If you're not using userChrome.css, non-default themes, or extensions, please provide the content of about support following these instructions.

  • Type about:support in the address bar, press enter.
  • Click Copy raw data to clipboard.
  • Come back to this bug, click the Attach new file button above your first comment.
  • Paste the content from your clipboard, add a description and hit Submit at the bottom.

Also, open the Web Console, and try opening the menu. Any error displayed?

(In reply to Francesco Lodolo [:flod] from comment #1)

The most likely cause is CSS customizations (via userChrome.css) or extensions that break your menu. Similar report here, with no answers from the reporters: https://www.reddit.com/r/firefox/comments/1hw67w5/firefox_update_broke_right_click_menu/

Are you using userChrome.css?

Does it work if you start Firefox in Troubleshoot mode?

I have the same issue and don't use any userChrome modifications. Troubleshoot mode doesn't work. So it's not extensions or css customizations.

And I think I know what causes it. Something about search engines in firefox broke with 134. Basically after update I have no search engines at all and I can't restore them to defaults too. What I think happens is when you right click on something with a text - you are supposed to get "Search %SEARCHENGINE% for text you clicked on", but since you have no search engines for some reason - it breaks the menu completely and there is a weird space in the menu there instead. What also supports this is that if you click on an image - the menu is fine since there are no search for entries in this case.

(In reply to LaterBoat from comment #3)

And I think I know what causes it. Something about search engines in firefox broke with 134.

AFAIK, search engines breaking tend to have a lot of side effects.

Also, open the Web Console, and try opening the menu. Any error displayed?

Do you see anything in the console?

@mike
Any advice on how to check if this is caused by a problem with search?

Flags: needinfo?(standard8)

Yep, removed yandex search engine (since it was the only search engine added by me before) from search.json.mozlz4 and everything works fine now. I'll try to figure out what exactly breaks it since adding yandex back works fine, so something about the formatting itself is breaking I guess.

Please can you check the browser console for errors, especially after start-up, if you are seeing the issue.

If you've got a specific version of a search.json.mozlz4 file in your profile that reproduces it, that would be useful for us to see. The file only contains details of your installed search engines and associated settings. I'm quite happy to receive via direct email if you prefer not to attach it to the bug.

Flags: needinfo?(standard8)

Here's the broken search.json.

And here's the relevan log I guess:

SearchService: #init: failure initializing search: TypeError: right-hand side of 'in' should be an object, got number
#migrateTo11 resource://gre/modules/SearchSettings.sys.mjs:777
#migrateSettings resource://gre/modules/SearchSettings.sys.mjs:663
get resource://gre/modules/SearchSettings.sys.mjs:187
SearchService.sys.mjs:1396:23
#init resource://gre/modules/SearchService.sys.mjs:1396

Search service failed to init SearchModeSwitcher.sys.mjs:273:15
#updateSearchIcon resource:///modules/SearchModeSwitcher.sys.mjs:273

Migration to version 11 is broken in this case for some reason.

@LaterBoat: Without the search.json.mozlz4 file, does that fix the context menu issue as well? I can't reproduce that in the same manner.

Flags: needinfo?(stopgolion)

Also, how did you originally add the search engine, Yandex to your settings? Did you do it through Firefox's UI, or by editing the file in some manner?

(In reply to Mark Banner (:standard8) from comment #9)

@LaterBoat: Without the search.json.mozlz4 file, does that fix the context menu issue as well? I can't reproduce that in the same manner.

What do you mean without the file? I removed the yandex search engine from the file and everything got fixed. Both the search engines and context menu are not broken anymore.

(In reply to Mark Banner (:standard8) from comment #10)

Also, how did you originally add the search engine, Yandex to your settings? Did you do it through Firefox's UI, or by editing the file in some manner?

With firefox ui, I edited the file now because the firefox ui (restore default search engines button in settings) also breaks.

Flags: needinfo?(stopgolion)

The issue is caused by the search settings migration that we added in bug 1655066. We changed how icon sizes were stored internally, and the migration for this is failing in some cases.

In the case of LaterBoat's settings file, the icon map is: _iconMapObj: { 64: "data:image/<image data>}.

However, we were expecting it to be: _iconMapObj: { "{\"width\":64,\"height\":64}": "data:image/<image data>} (the key is a JSON formatted object).

What we don't understand is how the settings made it into the bad state prior to migration. Firefox prior to 133 would have stored the JSON formatted width/height.

Some possibilities:

  • Something other than the Firefox UI was used to add Yandex to the settings file (an add-on, some website?).
  • The settings.json.mozlz4 file was used in a nightly/beta version and then copied back to an older release version.

It would be useful if we can get some idea of how the bad state was hit so that we have a better idea for future.

Status: UNCONFIRMED → NEW
Component: Untriaged → Search
Ever confirmed: true
Keywords: regression
Priority: -- → P1
Regressions: 1655066
status-firefox-esr115: --- → unaffected
status-firefox-esr128: --- → unaffected
tracking-firefox136: --- → +
Regressed by: 1655066
No longer regressions: 1655066

(In reply to Mark Banner (:standard8) from comment #12)

  • The settings.json.mozlz4 file was used in a nightly/beta version and then copied back to an older release version.

Yep, that's what happened most likely since I've switched back and forth from nightly to test another bug I had.

Assignee: nobody → mbeier
Status: NEW → ASSIGNED

Setting as S2 - as far as we're aware, this only affects users that have re-used the same profile across the 134 boundary (i.e. using 133, then 135beta, then back to 133 before upgrading to 134).

Please note that downgrades of profiles are not recommended, and that we have a specific dialog warning about potential issues if you do attempt this.

You can recover from the broken state by refreshing Firefox, or by removing the search.json.mozlz4 file from your profile. We will be adding a patch for this in the next dot release.

Severity: -- → S2
QA Whiteboard: [sng]

I'm having the same problem, context menu flooded with options. Following various pointers online to userChrome.css, I discovered that an empty or non-existent userChrome.css is fine, but having it empty other than a /* */ is not. This file has been around for a while (it had a use once, but when it no longer didn't I commented out everything instead of deleting it), but it hasn't caused problems until 134.

(In reply to 500-internal-server-error from comment #16)

I'm having the same problem, context menu flooded with options. Following various pointers online to userChrome.css, I discovered that an empty or non-existent userChrome.css is fine, but having it empty other than a /* */ is not. This file has been around for a while (it had a use once, but when it no longer didn't I commented out everything instead of deleting it), but it hasn't caused problems until 134.

Please can you check the browser console for errors similar to comment 8, I want to confirm that in your case it isn't related to the search service going wrong.

Flags: needinfo?(wooden35) → needinfo?(500-internal-server-error)
Pushed by mbanner@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/62c4e2cd5659 Fix search settings v11 migration fail when going back and forth between releases. r=Standard8
QA Whiteboard: [sng]
Whiteboard: [sng]

(In reply to Mark Banner (:standard8) from comment #17)

(In reply to 500-internal-server-error from comment #16)

I'm having the same problem, context menu flooded with options. Following various pointers online to userChrome.css, I discovered that an empty or non-existent userChrome.css is fine, but having it empty other than a /* */ is not. This file has been around for a while (it had a use once, but when it no longer didn't I commented out everything instead of deleting it), but it hasn't caused problems until 134.

Please can you check the browser console for errors similar to comment 8, I want to confirm that in your case it isn't related to the search service going wrong.

Unfortunately, I can no longer reproduce the problem. I managed to reproduce it once or twice, before it fixed itself for good.

Flags: needinfo?(500-internal-server-error)

https://hg.mozilla.org/mozilla-central/rev/62c4e2cd5659

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
status-firefox136: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 136 Branch
Attachment #9446784 - Flags: approval-mozilla-beta?
Flags: in-testsuite+

beta Uplift Approval Request

  • User impact if declined: Users switching back and forth between versions with the same profile will not be able to search and see broken context menus until they receive this patch.
  • Code covered by automated testing: yes
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: Add yandex opensearch engine in nightly. Open the profile in a pre 134 build (the version of the search.json.mozlz4 should be changed to <=10), open it in the build with this patch. Search should work as expected.
  • Risk associated with taking this patch: low
  • Explanation of risk level: minimal code change
  • String changes made/needed: no
  • Is Android affected?: no
Attachment #9446791 - Flags: approval-mozilla-release?
Attachment #9446784 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

release Uplift Approval Request

  • User impact if declined: Users switching back and forth between versions with the same profile will not be able to search and see broken context menus until they receive this patch.
  • Code covered by automated testing: yes
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: Add yandex opensearch engine in nightly. Open the profile in a pre 134 build (the version of the search.json.mozlz4 should be changed to <=10), open it in the build with this patch. Search should work as expected.
  • Risk associated with taking this patch: low
  • Explanation of risk level: minimal code change
  • String changes made/needed: no
  • Is Android affected?: no
Duplicate of this bug: 1941196
Duplicate of this bug: 1940859
Attachment #9446791 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9459093 - Flags: approval-mozilla-release?

release Uplift Approval Request

  • User impact if declined: Users switching back and forth between versions with the same profile will not be able to search and see broken context menus until they receive this patch.
  • Code covered by automated testing: yes
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing: Add yandex opensearch engine in nightly. Open the profile in a pre 134 build (the version of the search.json.mozlz4 should be changed to <=10), open it in the build with this patch. Search should work as expected.
  • Risk associated with taking this patch: Low
  • Explanation of risk level: Fixes to migration routines only.
  • String changes made/needed: None
  • Is Android affected?: no
Attachment #9459093 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9446791 - Attachment is obsolete: true
Flags: qe-verify+

Based on steps from comment 15 and comment 29, reproduced the bug on macOS 13. Here are the step used:

  1. Install 133 and open with a new profile
  2. Add Yandex search engine
  3. Install beta 135, open with same profile - all good
  4. Install release 134, open with same profile -with option - --allow-downgrade - here the bug is reproducible (cannot open link in new tab, context menu is "strange")
  5. Install release 134.0.1 and bugs seems to be fixed, search works as expected.
    The only concern is that after step4, downgrade to Release 134, the Yandex search engine icon is replaced with a magnifying glass, and remains the same on DOT RC 134.0.1. Should this be fixed in dot release 134.0.1?
Flags: needinfo?(standard8)

(In reply to Brindusa Tot, Desktop QA from comment #31)

   The only concern is that after step4, downgrade to Release 134, the Yandex search engine icon is replaced with a magnifying glass, and remains the same on DOT RC 134.0.1. Should this be fixed in dot release 134.0.1?

What is happening is that 135 has an additional migration (from bug 1655076) which further changes how icons are stored. In particular there's an _iconURL property which gets moved into a map detailing the icons, and so the _iconURL property is removed. In the case of Yandex, the icon is recorded in the map as a width of 64 pixels.

When a user forces the profile to be downgraded, the 134 version looks for the _iconURL property - which has been removed - and so falls back to looking in the map. However, it is looking for an exact match for a width of 16 pixels, and doesn't find it, hence we fallback to the magnifying glass.

The good news is that in 135, we also implemented a best fit method for looking up the icons from the map (bug 1655070). So once 135 is subsequently released, the icons will be able to be read and displayed again.

Flags: needinfo?(standard8)

I can confirm that after step 5, if I open with the same profile, Beta 135, the Yandex icon is displayed correctly.

Fix was verified on DOT Release build 134.0.1 on macOS 13, Windows 11 and Ubuntu 24.

status-firefox134: fixed → verified

Unfortunately, I can not reproduce this bug on Firefox 135 or Firefox 136. I tried with different scenarios based on steps from comment 15, comment 29 and comment 31.
Considering the above I cannot confirm the fix, I can just confirm that the bug is not reproducible anymore.

Flags: qe-verify+
Duplicate of this bug: 1943786
Duplicate of this bug: 1936719
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: