JavaScript DOM changes and can longer interact with page - javascript

I’m making a chrome extension and it's working. In this extension I parse data from a dynamic page, and then insert it into a new div which I then hide and unhide with the CSS visibility rule (via JavaScript DOM)
Problem is, after I hide the new div when done looking at it, the underlying page is no longer interactive. Can't click anything. Can't type into the interactive field to make updates etc.
Any ideas, anyone ever have an issue similar to this that they had to solve?!

The visibility attribute makes the element invisible, but it's still there and it takes up space. That is probably why it is blocking you from interacting with the content behind it.
Try instead using display: none;.

Related

How to manipulate the DOM of a React webapp (with Chrome DevTools)?

I'm using Chrome DevTools to inspect a React webapp. The app has an upload button with a hidden input field. I'm attempting to make the input field visible (and iteractable) in two different ways:
1) In the Elements tab, I find the input HTML tag and click on it. In the Styles panel on the right, I can see that the element has a CSS style applied to it, which sets "display: none!important;". When I uncheck this line in the Styles panel, the style gets disabled, and the input element shows up on the page (and I can click on it to open the file chooser). So far, all this makes sense to me.
2) In the Sources tab, I create a new snippet and I programmatically change the display style of the same element:
form = ...
input = form.getElementsByTagName('input')[0];
console.log(input);
computedStyle = getComputedStyle(input);
console.log(computedStyle['display']);
input.style.setProperty("display", "inline", "important")
console.log(computedStyle['display']);
When I run this, the console output makes sense: I confirm that I'm finding the correct element, the first time I print the display it's "none", and the second time it's "inline". However, nothing changes on the page, I don't see the input as in the other approach.
I'm still wrapping my head around React, and I suspect this is related to the fact that React can and will decide to recreate the actual DOM elements very often (so perhaps the input I'm changing is not the input I'm seeing?). But I'm not super clear, and either way, I was expecting these two approaches to have the same results. What happening here? And how can I programmatically change the hidden input to be not hidden?
You manipulate dom (in react) by changing props and state. There is a browser extension which let's you do that in browser. For chrome is here. There is extension for firefox as well.
I am guessing that your snippet change did not induce a React refresh, thus the shadow DOM was modified but React did not see a reason to update the DOM. Perhaps you could add a forceUpdate() in your snippet?

Hide frame from other frameset

I am trying to hide (or edit inline attribute) a frame from an other framset by clicking a button.
I used : $(".HiddenFrame").hide();
But seems that I can not find the item.
JSFiddle
"As far as my understanding of things goes, you need to perform actions like hide on divs. Basically, whatever you are trying to affect needs to respond to the css display attribute. If you must use frames, I would strongly suggest you use divs instead, then you will need to write some jQuery that actually removes the frame from the DOM instead of just trying to hide it."
Source :stackoverflow
and see this Link

Is it more efficient to keep DOM elements on the page or to re-render them as needed?

I have a dialog box that has settings associated with it. When the user clicks the "settings" button, a form is displayed so they can modify them.
What is more efficient:
to have the settings div exist hidden on the page and display when needed
OR
to create the settings div and populate it with data when needed?
In the first scenario you don't need to create the DOM elements and populate them every time, but if there are many dialog boxes open at once (a common situation) then the amount of elements on the page is pretty large and many of them are not going to be used often. But in the second situation, elements are created and appended to the DOM which gets expensive.
I'd suggest you to "cache" your html on the page, but enforce browser to do not render it until necessary (until user request the data, or simply scroll to it). The main idea is to add your html (with data) to the page, but comment it out. For example,
<div id="cached-html">
<!--
<div>
...some custom html here
</div>
-->
</div>
Then once user requested the html, you can do the following:
var html = document.getElementById('cached-html'),
inner = html.innerHTML;
html.innerHTML = inner.substring(4, inner.length - 4);
Pros. is that you don't bother your browser with initial rendering (later you can simply user display:none to hide it again), so your page renders faster.
And another note - if your data (and as a consequence inner html) changes frequently, then it will be better to re-render it each time user request it, but if it is almost static, then hide/show should be more effective.
There can be problems either way, it depends on your page. If you already have a lot of elements on the page, it may be better load add them when you need them. If your page is already very "scripty" you may want to load the elements and show them when needed.
The real question is what would be better for your page, more script, or more dom elements.
When you have to display same setting div at multiple places.
Keeping that hidden is a better solution.
Remember that creating a new dom element or cloning a existing dom element gives almost same performance, but for code clarity/maintainence cloning or template is better.
Implementation using template: Make a template of div setting and keep that hidden:
<div class="template_setting">
Your settings(children of template_setting)
</div>
Javascript/Jquery code:
-Whenever someone opens a dialogue box, make a clone of childrens of template_setting and append to div_dialogue.
-As you may have multiple templates on the same page( which is not always true).
Apply a custom event on the id of newly created setting div.( keep id of each setting div different, you can increment each one by some character/number).
$('#dialogue_opener').click(function(event){
$('.template_setting').children().clone().appendTo(div_dialogue)
.trigger('adjustSettingID');
Consider a hybrid solution. Load the "settings" div after the page is ready. This way, the user won't feel the extra "expense", and you'll have the div ready for when you need it.
I've typically seen that rendering from JavaScript is pretty darn fast. I've built lots of "just in time" menus, grids, and forms and the users can't tell the difference. The nice thing about it is that you don't have to keep a form current, just blow it away and default everything to the data in you settings object. Makes for cleaner code in my opinion.

How do I dynamically add a div element to any page from a Firefox extension/Addon

I am writing an extension for firefox which will be used to annotate pages on the web via a service. I would like to have a div or an overlay element (probably XUL based) at the bottom of the page which will let people annotate a page and save it. Something like what the Google Friend Connect does on this page, but via an addon.
This floating div/overlay should show up for every page on FF and should render contents from a web service. How do I start building this out?
If it is possible to access DOM via a FF plugin and alter it, then I would like to be able to add a floating div to the body of the document. But that doesn't work either. Example posted here: Dynamically adding a floating div to a page
There are several things you have to do:
You probably want to add some custom CSS to style the div. You can use the stylesheet service.
You have to attach an event handler to the load event ( or DOMContentLoaded), to be notified when a page finished loading. Have a look at Intercepting Page Loads and On page load.
You need a reference to element you want the new element append to. Tabbed Browser provides some useful information. E.g. you can get a reference to the body of the current selected tab gBrowser.contentDocument.body.
Regarding your code example: You forgot the give the element the CSS property position: absolute; or position: fixed; (you have a typo in your code, you wrote postion), depending on whether it should appear at the bottom of the page or the screen.
You can do this (because I have). To do it you'll need to find the node you want to change the content of (if you're adding to the bottom of the page, you may want to use the <body> node I guess) and then call one of:
insertBefore(theNewNode, afterThisNode);
insertAfter(theNewNode, thisNode);
Or possibly, but I'm not sure:
anExistingNode.innerHTML = anExistingNode.innerHTML + myNewContent;
That should be enough to get you started.

Stop certain elements from being edited inside a doc having designMode = "on";

I am using an iframe and setting its contendocument.designMode to "on". This allows me to replicate a Rich Text Editor, and achieve much more flexibility in the editing process.
The problem is that I have certain links (test) that are added to the page, and of course these links don't work because i'm in designMode.
At first I thought, well I'll just wrap that link inside another iframe, but still it won't fire the event attached to it.
Is there a way to have certain elements work as they would normally, even though they are inside a designMode="on" document?
Recently had the exact same problem. My solution was to use a div with contentEditable="true" instead of an iframe, which then allows you to set contentEditable="false" on elements within that div.
Not a perfect solution, but gets the job done in my case.
You can place a checkbox to toggle to designmode 'on' and 'off'. To see the action temporarily swich to designMode 'off'. This way you may be able to get the desired behavior of your script.
If you look at google docs, when you focus on the link, they show a small div with different actions for that link.
I guess they have spent already a lot of energy to make it the best they could. So I wouldn't try something different.

Categories

Resources