I have a pair of elements <file-location> and <file-location-dialog>. If the user clicks on the <file-location> with the intention of changing it, it fires a custom event file-change-request which is being listened for on its domHost by the <file-location-dialog> element. When it receives this request it stores the event.path[0] value from the request just received, pops up a dialog, gets the new location, sends of an ajax request to update the database and then fires back at the stored event.path[0] element a file-location-updated event. The original <file-location> element receives this response and updates the screen accordingly with the new location.
I originally developed this because I had a set of search results (potentially up to 400) each of which had this file location. I thought I would save on overall dom-elements by centralizing the only occasionally used dialog and ajax elements. This has all been working fine in the search dialog.
I have recently come to develop a different page of my application where the <file-location> element was needed again. However, without thinking about it, I have embedded the <file-location> element in the local DOM of a custom element <pas-appointment> whereas the <file-location-dialog> element sits in the custom element for the page, which uses the <pas-appointment> element inside a <template is="dom-repeat">
Again this "appears" to be working fine.
Obviously, there should be no problem with the file-location-request bubbling up the hierarchy of elements, but I suddenly just realised that in essence the file-location-updated is piercing the shadow dom as it seems to pass seamlessly through the <pas-appointment> boundary as though it wasn't there.
OK, so it works - so why am I asking the question? I am developing some another elements that are going to be of a similar nature. Before I rely on this design pattern can I be sure that it will continue to work as browsers properly implement the shadow dom specs. In particular what is likely to happen when we get to Polymer 2.0 and the web-components v1 specs?
Related
I'm about to finish developing an automated program on Python and the only thing that's stopping me it's a web element that gets immediately hidden when I try to inspect it from an OpenSea page (can't share the link here since it requires to be connected to my wallet):
So far, I have only managed to get the XPATH and the CSS_SELECTOR of this problematic element (div#tippy-298) which is the following:
button_problematic_xpath = driver.find_element(By.XPATH, '//*[#id="tippy-298"]')
button_problematic_css = driver.find_element(By.CSS_SELECTOR, '#tippy-298')
But what I need is to get the XPATH or CSS_SELECTOR of the Web Elements that button_problematic_css contains, more specifically the "Starting" and "Ending" Textboxes :
Also, just in case, the element that's on top of button_problematic_css is called "Duration", here's its XPATH:
button_duration = driver.find_element(By.XPATH, '//*[#id="duration"]').click #after clicked it deploys div#tippy-298 element
I was wondering if there could be any method to force the visibility of this button_problematic_css using the Chrome Console in the Inspection of Web Elements, or by using an specific method from Selenium on Python3.x to inmediately download all of the web elements this page has right after button_problematic_css is visible.
What I have tried so far is to manually inspect the element, by pressing Ctrl + Shift + C and and then clicking the elements contained in button_problematic_css which just ends up hiding this element before even clicking its content, the same happens when trying to display the contents of this element in the DOM of this page, it just dissapears.
I just wish my program could be capable of editing the dates in the "Starting" and "Ending" Textboxes
I guess you need to click the button to show the element. why did I guess? you need to show the url
or u can also try this code:
clickmore=WebDriverWait(driver, 2).until(EC.element_to_be_clickable((By.XPATH, 'blabalabla')))
self.driver.execute_script("arguments[0].click();", clickmore)
button_duration = driver.find_element(By.XPATH, '//*[#id="duration"]').click()
After several days of working, I managed to solve this, it happened that in order to get the XPATH from these particular elements, I had to use the Chrome Console and type $('#duration').click();.
In this case, #duration is a Selector that can be used to get the web element button that allows you to edit the period of time you want to set when clicked.
I guess the general statement would be something like this:
$('#your_css_selector').click();
Now, this way I could managed to look deeper in the DOM without making them hide again.
I'm building a component that uses an <iframe> to display another component. This component connects to an NGXS state which needs to reflect changes made to the state. After a lot of failures and testing I discovered the component will always only load the default settings of the state. I created a <button> to toggle a boolean and added an *ngIf to the <iframe> so I can force it to reload manually after trying things like this.Frame.(contentDocument || contentWindow).location.reload(true); didn't make any difference.
I created a stablitz app to demonstrate this issue however I think stackblitz blocks the use of <iframe>s in their platform so you might need to copy it into a local project to tinker with it. It's a simple app that shows the state outside of the <iframe> as well as inside with a button that toggles the <iframe> on and off so you can see how only the default values load after you update the value I have available for demonstration purposes. I'm not getting any type of errors and the issue isn't a matter of something being wrong with the code so I don't know what more to show that isn't in the stackblitz.
Does anybody know why and how <iframe>s do this and if there's a way around it? The only thing I can think to try is make a NestJS app to see if putting the data outside the app and making an API request from the component inside the <iframe> will be allowed, however I don't know why this issue is occurring to in turn know if that too won't be rejected for that same reason. How this can be handled?
The document running in an iframe is isolated from its host. They do not share memory- Angular does not provide a way to synchronize state between a host and an iframe on the page out of the box. The example is actually booting two Angular apps (one inside the frame and one outside). If you are using an iframe for security and isolation purposes, you'll need to devise a way to pass state between the host and the child via postMessage (and be aware that you are running two copies of your application). If this isn't for security/isolation, simply do not use an iframe to contain the child component.
I'm adding a blocking modal (ie one that covers the screen and prevents interaction while an API call is processing) to my company's design library.
As part of that, I modified our modal so that clicking on the grey backdrop will NOT hide the blocking modal, but I want to make sure that doesn't violate accessibility guidelines. I haven't been able to find anything online about this. Does anyone know if this this violates accessibility requirements?
Short Answer
The answer is 'it depends'. Basically if the modal is not dismissable in any way it becomes a 'keyboard trap' and so would violate WCAG.
However if you structure it correctly a modal that blocks the page while an API loads is perfectly valid (and can't be dismissed while the page is loading), but there are a few things you need to do to make sure this is accessible.
1. Make sure that when this modal loads, nothing else on the page is focusable.
The biggest issue I see on most modals is that they allow focus outside of them.
You can't just stop users using the tab key as that is not how most screen reader users navigate the page (they use shortcuts for headings (h1-h6), hyperlinks etc.).
For this reason make sure your modal sits outside of your <main> and the hide your <main> and other major landmarks that contain information with aria-hidden="true" and by adding tabindex="-1" to them so nothing is focusable.
Obviously this depends on your document structure so you would need to test it, but a properly structured HTML document will work with the above method.
2. Make sure that a screen reader user knows that the page is busy and something is loading.
There are a couple of ways to do this. The best is to use an aria-live region
Adding aria-live="polite" and aria-busy="true" to the section you are updating is one way (if you are updating one part of the page).
However in your circumstances I would make a section within the modal aria-live="assertive" and not use the aria-busy (as you will be hiding all the content in step 1 so aria-busy would not be applicable).
I would then update the message every second or two for long loads (i.e. 'loading', 'still loading', 'nearly loaded' etc. Or better yet a loading percentage if your script allows.)
Once the page content has loaded, you do not need to say 'loaded' instead make sure you have a heading for the section or page that has a tabindex="-1" added on it that accurately describes the content that has just been loaded in.
Once the load completes, programatically focus this heading and the user will know that the load is complete.
3. Make sure that if the API call fails you feed something meaningful back to screen readers
When your API call fails (notice I said when, not if!) make sure your JavaScript can handle this in a graceful way.
Provide a meaningful message within your modal aria-live region that explains the problem. Try to avoid stating error codes (or keep them short, nothing worse than hearing a 16 digit string on a screen reader for an error code), but instead keep it simple such as 'resource busy, try again later' or 'no data received, please try again' etc.
Within that region I would also add one or two buttons that allow to retry / go back / navigate to a new page depending on what is appropriate for your needs.
4. For long load times, let the user know what is happening.
I covered this in point 2 but just to emphasise it, make sure you feedback to users that things are still loading if there is a long load time by updating your aria-live region.
Nothing worse that wondering if the page has loaded and the developers forgot to tell you.
5. Give the option to cancel an API call so it doesn't become a keyboard trap.
Obviously the big problem with a whole page modal is it is a 'keyboard trap'.
To ensure this isn't an issue make sure you provide a cancel button.
Make sure it is clear that this will cancel the loading of the page, but don't rely on JavaScript alone.
Instead make this a <a> styled like a button that either points to the current page or the previous page (yet again depending on your needs) and add role="button".
Then intercept this click with JavaScript so that it can function like a button.
The reason for this is that when your JavaScript fails (yet again - when, not if) the user still has a way to get to a meaningful page, thus avoiding a keyboard trap.
This is one of the few times you should use an anchor as a button, as a fallback!
By doing this you ensure that the user always has a way to escape the modal.
You may also consider allowing a user to use the Esc key to close / cancel but that is yet again down to you and your circumstances.
In my project I'm working on styling some overlays. Because of the nested component structure I'm running into some problems here. The intended solution is to move the overlay somewhere closer to the app root while preserving data bindings, making the css styling less restricted.
I've managed to set up a prototype using Renderer2.appendChild(...). When the overlay is shown, the ngOnInit of the overlay appends the overlay to another DOM element.
With my current code I can either get the input or output binding to work (but not both), based on moving an empty comment <!----> found directly in front of the overlay.
From my understanding (Empty comments in Angular application) Angular needs this comment, but Renderer2.appendChild does not account for it (maybe it's not meant to be used for components, only for 'raw' html?).
Demo:
Here's the prototype presenting both issues I am stuck on: https://stackblitz.com/edit/angular-pg24om
Visibility of the overlays (shown below the labels) can be toggled with a button. The submit buttons inside the overlay logs the input to the console using an #Output event emitter. Pressing change text changes an #Input property.
Without moving the overlay, input and output binding works like expected.
Incorrect input binding: If I choose to move the empty <!----> comment together with the overlay, my input binding seems to stop working. Pressing Change text does not change the random number I pass to the component. Output binding still works fine in this scenario.
Incorrect destruction: If I don't move the empty comment, Angular fails to clean up the component when the visibility is hidden using the Toggle visiblity button. That said, while the component is alive both input and output binding remains functional.
If anyone knows how to get this to work, I'd greatly appreciate some help. I did see other methods of creating overlays using factory resolvers and detaching views, but being able to move the component while preserve bindings in the HTML template will save us a lot of time otherwise spent on changing a lot of components.
Edit: I forgot to mention that the error Error: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node. occurs when attempting to remove the overlay without the moved comment. Angular is attempting to delete a #comment element from the overlay, but it fails to do so because the comment is still in the div where the overlay template resides. That's the reason I tried to move the comment together with the overlay.
Hello all i want to ask how to reload the appended data ..
Actually i am having a page which goes infinite scrolling ..
and i need to reload the appending elements when clicked on a particular element ..
the loading is fine for the elements that are not appending (previously present when the page loads) .
loading by ajax is working fine (checked)
just wana ask how to use load method of ajax for the divs in the appended data..
$("#abc").load("load.php #abc");
I think you have a problem with your events. If you are using the .click or .bind event handler of jQuery, the new added elements will not be targeted. Try $(".clickable").live("click", function()); to make also the newly added elements clickable.
As jQuery documentation says:
http://api.jquery.com/live/
Attach an event handler for all elements which match the current selector, now and in the future.