setting tabindex in firefox ends up tabbing into the browser tab - javascript

so I have an app with several buttons:
<button tabindex='1'></button>
<button tabindex='2'></button>
<button tabindex='3'></button>
however tabbing ends up moving the tab focus to the actual tab of the browser instead of going to the next button (ie. it ends up focusing on Firefox's tab user interface instead of tabbing into the website's button)...any idea why this could possibly happen?
note: I can't paste in the real code I use since it is much more complicated and involves complicated javascript, etc hence it's difficult to paste them in into here however the change I made was that I made 3 button elements have tabindex attributes in ascending 1,2,3 order...

Related

Performance issues when focusing inputs in modals?

So, I've probably stumbled upon the strangest bug/feature I've ever seen. I've developed a website which helps you read foreign books. See this book (or any book on the website, it doesn't matter): https://anylang.net/en/books/de/heaven-has-no-favorites/read.
Try to quickly move your mouse hovering on words/sentences, maybe click on something etc. Everything should work pretty smooth.
On mouseover a word quickly becomes orange, on click the translation quickly appears etc.
Now click on the login button:
The first input should become focused.
Then close the modal and try the first step again. Everything becomes very laggy. The lags won't disappear no matter what you do, except:
Click on the page number:
Lags disappear. Completely.
The same result (lags) can be achieved by:
Clicking on a word inside a translation tooltip
It has a contenteditable attribute, so the behaviour is exactly the same as in the first case.
Click anywhere outside the tooltip, closing it and causing the lags.
Lags still disappear if you click on a page number (or, probably, any input[type="text"] on the page (but not in modals))
Some things to consider:
The effect doesn't disappear if you lose focuse in a modal and then close it.
The same effect can be achieved by focusing in a modal and then manually removing a modal from dom. So javascript is not the problem.
If you don't remove a modal from dom but apply "display: none" to it instead, everything is ok, no lags.
My guess is that the browser gives higher priority to elements where input[type="text"] is focused and doesn't respect it when an element with the input is removed from dom. Any other ideas? This thing really boggles my mind.
If you do a performance profile of your site while going through this process, you'll see that your memory allocation continues to climb as you interact with the page. You'll also notice that the more text you hover over the worse the lag eventually becomes.
This is indicative of a memory leak in your code - possibly caused by event listeners that aren't being cleaned up properly.
Without an in-depth review of your code it's unlikely anyone here is going to be able to pinpoint where the exact problem is, but hopefully I've pointed you in the right direction!

Multiple tinymce textareas on one page -- correct chrome menu not always appearing

I have a page with multiple tinymce textareas, using the browser's default context menu. The issue I'm having is that sometimes Chrome will show the correct textarea context menu (cut, copy, paste, etc.), but every second time I open the context menu (roughly), it shows the non-textarea content menu (back, forward, reload, etc.)
I've a sample Fiddle here demonstrating the issue: http://fiddle.tinymce.com/Bugaab
If you right click in either text area (in Chrome) a few times, in different locations, the different menus will appear.
I'm fairly sure I'm initializing the controls correctly. The problem doesn't occur with only a single textarea.
Any help appreciated.
Not quite. It's not a tinymce context menu at all. That's Chrome's context menu when it opens inside an input or textarea. It has different menu items depending on the context.
I said earlier that the issue didn't occur when only a single tinymce textarea was on page, but I see now this was incorrect. The issue happens for every tinymce textarea.
I think the problem is to do with the area of the textarea. Tinymce hides the actual native textarea control and draws its own, and it’s probably incorrectly mapping the dimensions somehow, confusing Chrome into thinking the mouse click is outside the control.
From what I’ve seen, the norm with this control is to use its own context menu rather than rely on the browsers, which is probably why I’ve had such difficulty finding mentions of the Chrome problem anywhere.

Safari Elements Disappearing After jQuery Interaction

I'm having some strange issues in Safari on Mac desktop and on iOS on a site currently being built. It seems that when there are jQuery interactions with elements, the elements disappear. When I inspect the element, I can't see any properties that indicate why the element would be hidden. If I toggle one of the checkboxes on any of the CSS properties for the element, it reappears.
Steps to Recreate
In Safari, go to: http://bisqitstage.promotw.com/
Refresh the page using the refresh button (not by hitting return on the URL).
Click the darker area (intended checkbox) to the right of "I agree to the terms and conditions of the site.".
Here is where you should see a checkmark appear based on the jQuery event.
Right click the box area and choose "Inspect Element".
In the HTML inspector, within div.bisqit-checkbox click on div.glyphicon.glyphicon-ok.check.
Scroll down within the CSS inspector and toggle the checkbox next to any of the property options (for example, uncheck and then re-check width: 35px;).
The checkmark will now be displayed
Expected
After step 3, the checkmark should be displayed after step 3. When inspecting in step 6, if you chose "width" for instance, the property was already checked. Unchecking it and checking it again shouldn't change it's state - so why does it not display after step 3?
I'm having several issues similar to this within this site build. I've tried different jQuery versions as well as removing other components that might be interfering, but cannot seem to resolve the issue.
Browser Version: Safari 7.1 (although we've noticed it back to v6).

How can I inspect disappearing element in a browser?

How can I inspect an element which disappears when my mouse moves away?
I don't know it's ID, class or anything but want to inspect it.
Solutions I have tried:
Run jQuery selector inside console $('*:contains("some text")') but didn't have any luck mainly because the element is not hidden but probably removed from the DOM tree.
Manually inspecting DOM tree for changes gives me nothing as it seems to be just too fast to notice what have changed.
SUCCESS:
I have been successful with Event breakpoints. Specifically - mousedown in my case. Just go to Sources-> Event Listener Breakpoints-> Mouse-> mousedown in Chrome. After that I clicked the element I wanted to inspect and inside Scope Variables I saw some useful directions.
(This answer only applies to Chrome Developer Tools. See update below.)
Find an element that contains the disappearing element. Right click on the element and apply "Break on... > Subtree Modifications." This will throw a debugger pause before the element disappears, which will allow you to interact with the element in a paused state.
Update Oct 22 2019: with the release of v. 70, it looks like FireFox finally supports this kind of debugging 2 3:
Update Sep 15 2020: Chrome has an "Emulate a focused page" option (you can get it from the [⌘]+[P] Command Menu, or Global Preferences) for this exact need. 5 - h/t #sulco on Twitter
An alternative method in Chrome:
Open devTools (F12).
Select the "Sources" tab.
While the element you want is displayed, press F8 (or Ctrl+/). This will break script execution and "freeze" the DOM exactly as it is displayed.
From this point, use Ctrl+Shift+C to select the element.
Open console
Type in setTimeout(()=>{debugger;},5000);
Press Enter
Now you have 5 seconds to make your element appears. Once it appeared, wait until the debugger hits. As long as you don't resume, you can play with your element and it won't disappear.
Useful tip to avoid repeating those steps above every time:
add this as a bookmarklet:
Bookmark any page
Edit this new bookmark
Replace the URL/location with: javascript:(function(){setTimeout(()=>{debugger;},5000);})();
Next time you wish to use this, just click/tap this bookmark.
Verified in 2022
Do the following:
Open the console and navigate to Elements tab
Type command + shift + P (OSX) or control + shift + P (Windows)
Type the word focused
Select Emulate a focused page from the the menu
Now clicking around in the console will not close the element.
I am using chrome on Mac there I've followed above steps but I'll try to explain a bit more:
Right click and go to inspect element.
Go to sources tab.
Then hover on the element.
Then using keyboard F8 or Command(Window) \. It will pause the screen in a static state and the element won't disappear on hover out.
In Firebug there are different solutions for this:
You can use Break On Mutate inside the HTML panel. (with this you'll also be able to find out which element it is)
You can right-click the element and choose Inspect Element with Firebug
Also you may want to follow issue 551, which asks for a way to temporarily block specific events.
Edit:
To find out which element it is you can also enable the HTML panel options Highlight Changes, Expand Changes and Scroll Changes Into View to make the element visible inside the HTML panel.
Sebastian
In my case, I used Expand recursively option on google chrome:
The steps are:
Inspect the dropdown field
Find the dynamic DOM (the purple highlight)
Right-mouse click on that dynamic DOM
Choose Expand recursively:
We can see all elements are there
Here is a demo:
Hover over the element with your mouse and press F8 (this in Chrome) to pause the script execution. The hover state will remain in visible to you.
It take you to the sources tab.
Go back to Elements tab. This time code will not disapper.
There Could be Dom element and the controller functions fighting at to refresh the session. Running the application by "Start without debugging" helped in my case.
enter image description here
you can view the elements appearing and disappearing in the inspector under elements. If you navigate to the element when it is visible you should be able to see it disappear or see its css change when it status changes.
This is possible with firebug in firefox or the built inspector in chrome.
I've written an article about debugging CSS of disappearing elements
Using hotkeys to automatically go into debugger mode with hotkeys keyboard shortcut:
Install the shortkeys extension
Click on the extension icon and chose "options":
Configure as follows:
Click "Save shortcuts" button (bottom-right)
Now, go to any page, make sure devtools is opened, and hit CTRL+SPACEBAR keys, while your inspection target element is visible.
I'm using Windows OS and this hotkeys combination is good for me and is not "taken" by any other shortcut, but of course, you can choose any other.
i had the same problem but i use Firefox it disappear as soon as i open inspect element found a solution:
open the 4 dashes(settings) go to web developer > Debugger and immediately press F8 which is the shortcut for the pause that stop the script before it kick and detect that you opened the developers tools

Does a browser perform selection of corresponding Javascript to screen elements?

Right Click, inspect element allows me to see corresponding html & css to screen element. Does the browser likewise, permit tracing the javascript function to corresponding clicks? Or do you manually need to trace from onclick event, so on and so forth?
If so, can one likewise, perform editing of the Javascript, in a browser to verify, what changes will it bring about? Much like, what we can do for html & css
On Google Chrome i discover, in Elements on the right side screen, one can browse to Event Listners then click event to see some Javascript. I'm still deciphering it to see if it permits simultaneous browser screen manipulation.
It doesn't seem to be working at the moment.

Categories