I was trying to figure out how to get some focus/blur behavior working for something when I ran into a really strange and annoying behavior in the Chrome debugger where I got an infinite loop while trying to debug an onfocus handler. It seems to be related to any action which takes focus away as I've been able to reproduce it using alerts instead of a breakpoint.
Here is my minimal example. Make sure you open this in another tab. Closing the tab is the only way I've found to end the loop.
https://codepen.io/cebo494/pen/OJxVZxq
Is this a known issue? Is there an easy workaround other than just using print statements to debug everything?
My final goal in my actual handlers isn't to take away focus, so it's not a problem if this is just a bad practice that I should avoid, but it's super annoying not being able to use the chrome debugger for my focus callbacks.
This seems to be specifically a Chrome issue, as the loop didn't occur in Firefox or IE. It only happens in Chrome and Edge (which is chromium)
I tried the sandbox, it actually got triggered on Firefox as well. I think the problem is that when you close the alert, the focus is lost on the button, but React internally re-focus on the button again, therefore trigger another onFocus call.
I would set a flag to manage the alert behavior, and reset the flag during onBlur event:
const [alert, setAlert] = useState(false);
// you can also pass event to implement the onblur method in the same function
const alertInfo = () => {
if (!alert) {
alert("focus");
setAlert(true);
}
}
Or if the event is only triggered by mouse, you can also use onmouseup/onmousedown to handle the event.
Related
I get this error in the Chrome console every time I try to evaluate an expression.
EvalError: Possible side-effect in debug-evaluate
What could be causing it?
I think I found the issue, reading through a discussion on an electron issues board.
It could potentially be caused by this: [inspector] Add custom error dispatch machinery for debug evaluate.
And hopefully fixed in this: [inspector] Don't trigger window.onerror with side-effects disabled.
This was an oversight in https://crrev.com/c/3557234, which led to a really weird developer experience: once a window.onerror handler was installed, typing into the Console or other side-effect free debug evaluations triggered this handler.
The website you are inspecting contains an onerror event listener.
A new bug in the latest version of Chrome triggers this event every time an expression is evaluated in DevTools. This includes live expressions and the console.
If this is your own website, add this line of JavaScript to your event listener to ignore any errors triggered outside of a script, where script is the second argument of the event listener function:
if(!script.endsWith(".js")) return;
Note that this will only work for external JavaScript (in .js files), in the case of JavaScript embedded in HTML <script> tags, it will disable your event listener entirely.
If this is not your website, you can temporarily disable the event listener in DevTools, like this:
At the top of DevTools, open the "Elements" tab
Press "ยป", on the right of "Styles", "Computed", "Layout"
Choose "Event listeners"
Find and expand "onerror"
Click "Remove"
This will remove the event listener, but the issue will return after you refresh the page.
Hopefully the next version of Chrome will fix this bug.
I am developing a Chrome extension that adds a custom devtools panel. My panel has some text boxes that allow user input, but any time I type a question mark, it opens Chrome help instead of tying the '?' character. Is there a way to stop this behavior?
UPDATE:
I should have mentioned that I'm using React in my extension and that I was using React's synthetic events.
This turned out to be unrelated to Chrome and due to a React JS nuance.
I was trying to call event.stopPropagation() on a React synthetic event which doesn't actually stop propagation to non-react registered event handlers such as the one that opens the help dialog.
The fix was to register a keydown event to the native DOM element and calling stopPropagation on the native event. This properly stoped the help menu from opening in response to typing in my input.
e.g.
<input
ref={input => input.addEventListener(event => event.stopPropagation())}
onChange={this.myOnChangeHandler}
/>
I'm looking for an event that can be fired just right before changing a tab?
I have already seen this post, and I have also looked into the tabSelect event in the firefox extension, but I couldn't find any event that can be fired just before the tab change.
Unfortunately there is no such event.
However you can watch, with a MutationObserver, the type attribute of selected tab's browser element (gBrowser.mCurrentBrowser). When it changes from content-primary to content-targetable it's a signal that a tab switch is in progress.
As paa already noted, there is no event that happens before a tab is selected. What you can use are tricks, e.g. the Object.watch() method (yes, using it isn't exactly recommended). It allows you to listen to changes of the gBrowser.tabContainer.selectedIndex property (the setter of this property is where the select event is being fired):
gBrowser.tabContainer.watch("selectedIndex", function(prop, oldval, newval)
{
// New tab being selected, do something here!
return newval;
});
The advantage of this approach: by returning oldval from the handler you can prevent the selection from taking place.
I would like to call a function when the Chrome window is closed. I can do it in Firefox and Internet Explorer, but I cannot do it in Chrome.
window.onbeforeunload = function () { return "Sure ?"; }
It is working on 2 browsers! If the function does not return "Sure ?", then it seems to work in Firefox and Internet Explorer. Could someone help me with this issue please?
You may refer to this question: there is no such event in the Chrome Extension API.
Why do you want to return a string? You need to learn Javascript a bit more to understand how return works in event listeners and why returning gibberish won't do much.
Often, in event handlers, such as onsubmit, returning false is a way to tell the event to not actually fire. So, say, in the onsubmit case, this would mean that the form is not submitted.
Some event listeners act differently when false is returned. The onbeforeunload event doesnt't respond to it though.
I'm making a chrome extension that uses pageAction.
I can set when it shows whether I want it to have a popup or handle the click myself.
What I want to do is handle the click myself, but with certain scenarios I don't want to process the normal code, and want to show the user a message. Preferably with a popup.
But it seams I can either make the pageAction have a popup or have an onClick. But not both.
I can show an alert, but that is ugly.
Currently, there is no "neat" or official way to handle both. You can just do either. But there are some work arounds that some Google extension product have done.
First of all, set it up to show the popup. And within your pageAction popup, you can have the initialization code to be something like this:
Page Action Popup:
function init() {
if (getClickBehaviour() == 'popup')
handlePopup();
else
openPage();
}
function getClickBehaviour() {
return localStorage['CLICK_BEHAVIOR'] || 'popup';
}
function openPage() {
chrome.tabs.create({url: 'http://google.ca'});
window.close();
});
}
init();
Then you can let your options, set the click behavior. If you want different behaviors on each click, you can do that too.
As you noticed, we are closing the popup right after for the "default" behavior that we don't want the popup to show. That is currently the only way to implement different behaviors.
I haven't tested this myself yet, but have you tried setting the popup to the empty string when you want to handle the click (chrome.pageAction.setPopup('')) and to your popup when you want to show a message. I'm not perfectly sure if the onClicked event handler gets called in that case (where the popup is dynamically set to the empty string), but it's worth looking into.
As far as I know, there is generally no way to programmatically open a popup window for a page or browser action. (Which is too bad, I would love this functionality; but you can imagine some of the annoyances if this were possible.)