Hopefully everyone knows the benefit of setting the HTML accesskey property on input-fields and buttons (and various others): It makes the page easy to navigate by enabeling shortcuts (in IE by pressing 'Alt' and the accesskey).
My problem is now that I have been asked to look into extJS for building our forms (and web stuff en general) as this is delivered with our IceBreak server.
I've been able to build a form and at first I figured that I must be able to set the accesskey the same way as all the other properties... but that does not seem to be working =0/
I can see in How to implement accesskey on ExtJs tabs? and http://www.sencha.com/forum/showthread.php?22812-AccessKeys-(Global-keymap) that it is possible to make something similar to accesskeys, but they seem a lot like work-arounds to me.
I just need for Alt and 0-9 or a-z to focus/active the elements. Nothing more fancy than that.
Is there a SIMPLE way of getting extJS to set the accesskey? (preferably on the html-element)
I was about to suggest using the KeyMap component, but I see that the forum links already do that. I have used the keymap object before to create keyboard shortcuts in the past. We replicated the keyboard shortcuts that existed in the thick-client legacy application we were replacing.
If you follow the guidelines in the links you posted, that should get you to where you are going. Following this method is what you'll need to do.
Related
Long time automation developer here (just for context).
It's been bugging me for quite a while that the dev tools in chrome used to find elements just don't seem to work as I expect. Hopefully someone can point out what I'm doing wrong.
Looking at , say, sauce labs page: https://saucelabs.com/blog/selenium-tips-finding-elements-by-their-inner-text-using-contains-a-css-pseudo-class
ok now that page has div's and anchors
and indeed I can do find ('a') or find('div')
but why do I have a problem using classes or id's ?
The find() method refers to window.find(), a non-standard API for the browser's built-in Find function. It does not find web elements the same way Selenium or Capybara do, and so it does not parse the input as a selector.
You find elements with selectors in Chrome DevTools using document.querySelector() or document.querySelectorAll(). There are no special methods in Chrome DevTools for this, however it does provide the $() and $$() aliases (respectively) to save you time and keystrokes.
You can use jquery code in chrome console, for example if you want to find something with class of "foo" you can write $('.foo') or a id of "bar" you write $('#bar')
You can read all about it here
Also you can just google what you want "Jquery how to find a div with id"
Currently, I am working on a program that converts an html page into a PDF using the iText Library.
The Checker that I am using is PAC3 -->PDF Accessibility Checker 3 which is described by the following link (https://section508.gov/blog/check-pdf).
One of the issues is the “Alternate description missing for an Annotation”
An excerpt from the following link explains it:
http://www.uottawa.ca/respect/sites/www.uottawa.ca.respect/files/fss-fixing-accessibility-errors-in-pdfs.pdf
Alternative description missing for an annotation This usually happens when the link is not clear enough. To fix this error, add alternative text to the link tags. To add the alternative text, please do the following;
In the tag tree, select the tag for the link, and select Properties
from the options menu.
In the Touchup Properties dialog box, select
the Tag Tab.
Type alternate text for the link, and click close
I have been trying to use iText to fix this problem, but googling, looking at the source and reading the documentation does not help.
Does anybody have any suggestions on how to either write the HTML or use the itext problem to get rid of the “Alternate description missing for an Annotation”
Thank you for your help
You did not specify whether you using old code (XMLWorker, HTMLWorker) or new iText code (pdfHTML).
This of course impacts the proposed solution.
In my answer I am going to assume you are using pdfHTML
There are several options:
edit the incoming HTML using a library like JSoup
convert the incoming HTML to iText IElement objects, and edit those, setting properties where needed
write your own custom TagWorker that handles all instances of a specific tag, and write custom logic to deal with the missing annotations.
An example of a custom tag worker can be found here:
https://developers.itextpdf.com/content/itext-7-examples/converting-html-pdf/pdfhtml-custom-tagworker-example
I have an control, to which I want to add a custom html attribute called, previousValue.
The Salesforce Developer's Guide assures me that I can do this by prefixing the attribute name with html-.
So I have an element that appears thus:. I also have the docType="html-5.0" attribute in my page control.
However, in Eclipse I get an 'unsupported attribute' error. I have upgraded to the latest force.com IDE; can any one tell me why this isn't working? What else do I need to do?
Thanks.
After much experimentation, the answer to this seems to be that the salesforce developer's guide is inaccurate and the 'hmtl-' prefix is not supported by the <apex:inputField> component. I can add it without a problem to an <apex:outputPanel> component. Don't understand why this should be so and the whole point to using these attributes is to locate data in a relevant place and avoid complex jquery selects to find the data relative to the location at which it is required.
I work at a gym at the front desk. The website we use takes awhile to navigate using the GUI. This console in the Google Chrome browser seems pretty powerful. Can someone please direct me to some sort of tutorial or even answer this question yourself?
How would I use the Google Chrome console (inspect element > console) to perform searches using the website's search ability?
Thanks for your help!
You will need some basic understanding of javascript and DOM to do this.
If your site has a simple form for searching, you could use something like this.
document.getElementById('IdOfSearchField').value = 'test';
document.getElementById('IdOfSearchForm').submit();
What is does is that it fiends the searchfield and sets its value to "test" and then it submits the search form.
On this site (sorry for it being in Swedish, it was the one I was currently working on) you could use the following to search for 'test'.
document.getElementById('query').value = 'test'; document.getElementById('SpeedSearchForm').submit();
If your site has jQuery loaded you could simplify this a bit.
$('#query').val('test'); $('#SpeedSearchForm').submit();
Another way of doing it would be to navigate directly to the searchresult-page with the proper querystring (if that is supported by your website. In my sample case, it would look like this (because the search page is located at /search and just need the querystring query to work).
window.location = '/search?query=test';
But as ajp15243 noted in the comments on the question, it all depends on how your site is built. It's also a bit messy to type all that for every search.
I've noticed that browsers don't recognize my password field as a potential auto-complete target. I'm assuming this has something to do with the fact that the password field isn't in the original HTML - it's created by my GWT script after the page has loaded.
Is there a way to tell a browser, "hey, here's this form, treat it like usual?" How can I let browsers hook into my app for autofill?
There are some workarounds to get the browser to auto-complete your login like the one described here.
After struggling some time with it I strongly suggest you simply wrap an existing form of your host page (do not generate the inputs with GWT), do a form.submit() on it and have a servlet listen to the request.
I believe that password fields ( tags with type="password") are not auto-filled for fairly obvious security reasons. It doesn't matter that the field is added after page load by your GWT script.
Try mimicking the field in regular HTML and compare that to how your GWT app creates the DOM structure. Perhaps your GWT app is putting the page together differently?