Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selector improvement and code cleanup #3369

Open
wants to merge 1,188 commits into
base: current
Choose a base branch
from

Conversation

FaySmash
Copy link

@FaySmash FaySmash commented Mar 2, 2024

Improved the download button selector and removed unused and non-functional code (still WIP)

The old code only worked on the English version of the Chrome Web Store because it searched for "Add to Chrome", which changes with different localization. I made the selector generic to work on all languages. I also found that the function parentNodeUntil doesn't get called and the browser.runtime.onMessage and browser.runtime.sendMessage don't work and also don't have any purpose (?).
The installation still doesn't work tho, also the uninit function doesn't get called so this PR isn't final but servers as a base for further improvements.

jamesteow and others added 20 commits March 6, 2024 15:58
…ty and loosen restrictions on component types - r=Standard8, a=dsmith

Differential Revision: https://phabricator.services.mozilla.com/D201313
So as to not change load timing from stylo threads.
…y during release a=diannaS

The causes of the runnable loop are as follows:
1. In Release we have a special case to make sure OnStart&OnStop are always
   called. We do this by dispatching a runnable that calls DoNotifyListener.
2. DoNotifyListener is called, then the reference to the channel is again
   dropped. But at this point only OnStartRequest was called, and
   ContinueDoNotifyListener was added to mEventQ. That means another
   runnable would be dispatched.

While the loop was broken in the previous patch, we still want to ensure
OnStopRequest is called before the channel is released, so this patch
adds an argument to DoNotifyListener to select whether ContinueDoNotifyListener
should be called synchronously or dispatched to mEventQ.

Original Revision: https://phabricator.services.mozilla.com/D202798

Differential Revision: https://phabricator.services.mozilla.com/D204063
…X_115_9_0esr_BUILD1 a=release CLOSED TREE DONTBUILD
…X_115_9_0esr_BUILD2 a=release CLOSED TREE DONTBUILD
…ration r=spohl a=RyanVM

This removes all the memory allocations which we were doing while writing a
minidump of the crashed process from within the process itself. Under these
conditions all threads are stopped save for the minidump writer; so if another
thread owns a mutex guarding the memory allocator we could deadlock by doing
allocations.

This patch avoids allocating strings entirely and uses Breakpad's alternative
allocator to sidestep the issue where we cannot avoid allocations.

Differential Revision: https://phabricator.services.mozilla.com/D201960
…X_115_9_0esr_RELEASE a=release CLOSED TREE DONTBUILD
…eadfp r=saschanaz

readfp is deprecated since Python 3.2

Differential Revision: https://phabricator.services.mozilla.com/D190532
@FaySmash
Copy link
Author

Sorry for the mess in commits - if your rebase your change ontop of the latest HEAD, should get cleaned up (may require a force push to your branch).

I tested this, but when en-US remains the default, the button detection no longer works at all.

Hi Alex, thanks for getting back at me. I changed the JS Selector to identify the button to this: (document.querySelectorAll('main > div > section > section > div > div > button'))[0]

Which works in my case:
Screenshot 2024-03-20 185504
(also tested on other browsers)

As I noted, this PR is not final and still needs work (currently even if the button appears, the installation still doesn't work)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.