How to edit the DIV which renders only runtime. which is not present in HTML page? - html

I have a small web app which has <a href="> tag which renders the only runtime I mean it does not appear in HTML page it appears only in chrome developers tools. How to eliminate such kind a tag and override or edit it.
I tried editing code via its script when I inspected for long it split document.querySelector("#m360CrA483349594983") but when I search entire project there's no sign of it!
demos written can be eliminated for sure!
Even I tried to Enable Local Overrides on but nothing seems to work that mysterious tag is kept coming saying
"demos written can be eliminated for sure!"

once the dom is ready you can access the element
<script>
(function() {
// the DOM will be available here
document.getElementById("m360CrA483349594983");
})();
</script>

Add body onload event listener in order to search for tag appearing at runtime.
Also, pay attention to tag ID value, it seems it is generated every time, so, you won't be able to find it by static ID

Related

Using node and node-phantom to scrape AngularJS Application

I have a node script set up to scrape pages from an AngularJS application and then generate code needed for testing purposes. It works great except for one thing. ng-if. Since ng-if removes elements from the dom the script never sees these blocks of code. I can't remove the ng-if's. So I'm wondering if there is some way to intercept the html between when node-phantom requests the page and when it actually loads everything in to phantoms dom. What I'm hoping to do is simply set all the ng-if's to true so that all content is available. Does anyone have any ideas for this?
EDIT I'm using phantomjs-node not node-phantom.
My Final solution was to scrape the page for all of the comment tags. Then filter through to find the ones that contained ng-ifs and parse out variable names from those tags. Then I tapped into Angular's $scope and set all of the variables to true. Forcing everything that is hidden on the page to be visible.

Is there a way to bookmark or link to a section of a page without an anchor?

Is there a way to bookmark or link to an HTML page (which I am not author of) without having an anchor in the HTML code?
I want the page to get scrolled down to a particular section when accessed from a bookmark or hyperlink even if there is no anchor tag in the destination page.
Note: the destination page has an anchor tag as "foo" then bookmarking like http:/...hello.html#foo will not only take the user to hello.html, but also automatically scroll down to the section of the page so that the anchor tag "foo" is at the top of the screen.
It's the year 2020, there is a draft by WICG for Text Fragments, and now you can link to text on a page as if you were searching for it by adding the following to the hash
#:~:text=<Text To Link to>
Working example on Chrome Version 81.0.4044.138:
Click on this link Should take you to another answer page and highlight the link there
You only need to have the appropriate id attribute on an element to use it like a bookmark...
Test
...
<p id="test">Hello world</p>
See the W3C specification: Anchors with the id attribute
Older specifications also allowed navigation based on the name attribute, but this attribute has been removed from the latest HTML specifications (but if there is a name attribute it may be used in the same way as an id attribute).
If there is no id or name attribute where you wish to navigate to, there is no way of navigating to the specific point within the page, only to the page itself. In this case you may want to quote the pertinent information and supply a citation with a link or perhaps ask the author if they would add an id.
This is a copy of #AbderrahmaneTAHRIJOUTI's answer but updated with some extra info.
It's the year 2020, and now there is a draft by WICG for Text Fragments, and now you can link to text on a page as if you were searching for it by adding the percent-encoded quote to the URL like this:
#:~:text=<percent-encoded-text-quoted-from-site>
For example, this link highlights the syntax from the spec.
One can also highlight multiple sections as well by chaining query parameters with ampersand (&):
#:~:text=<quote-1>&text=<quote-2>
For example, see these highlights to the spec.
Even ranges can be set in case of a longer quote (at least in Chrome):
#:~:text=<begin-text>,<end-text>
For example, highlighting an entire paragraph in the spec.
For some reason, in Chrome 89.0.4389.90 the above links may only work if one (1) clicks on them, (2) goes to the address bar by clicking in it or by F6, and (3) hits Enter. Not sure why this is when Google search constantly offers links like this in the results which work out of the box (e.g., a link to Azure Vault)
Support
It's still spotty, but most major browsers support it (except for Firefox...). To check the current status of adoption, check out https://caniuse.com/?search=%3A~%3A
There is a relatively recent W3C Working Group Note on Selectors and States which would allow linking to selected text.
Here is a Firefox webextension partially implementing the link format (allowing you to "create" a link, based on the selection, as well as, obviously, open such a link, highlighting the correct selection):
https://addons.mozilla.org/en-US/firefox/addon/precise-links/
As of 2019 it seems to work fine.
Its source code is available here.
The Firefox extension "Web Marker" does exactly what you want.
https://addons.mozilla.org/en-US/firefox/addon/web-marker/
You can find its source code and documentation here:
http://liveurls.mozdev.org/tech.html
If the page supports being embedded as an iframe, you can link to a document that embedds it and then autoscrolls the document. The issue is that we can't get the height of the page, so instead we just hijack the scrolling event to make the page taller once we approach the bottom:
data:text/html,<html><body style="margin:0; padding:0;"><iframe id='i' src='http://forecast.weather.gov/MapClick.php?CityName=Las+Vegas&state=NV&site=VEF&textField1=36.175&textField2=-115.136&e=0' width=100% frameborder=0 margin=0 scrolling=no style="height: calc(100vh + 170px + 200px);"></iframe></body><script>window.scrollTo(0, 170);window.onscroll = function(e) {if((window.innerHeight + window.scrollY) >= document.body.offsetHeight - 200) {document.getElementById('i').style.height = window.innerHeight + window.scrollY + 200;}};</script></html>
Modern browsers will try to scroll to an element with an ID that matches the hash part of the URL (i.e. if you have <h1 id="foo">, then #foo would get you there).
If everything else fails, you can use jQuery. Get the hash part from the document URL with window.location.hash. You can then interpret that in JavaScript to determine an element in the page.
Use scrollTop to move there (see Scroll to an element with jQuery).
See also: https://api.jquery.com/scrolltop/
I must be not getting something, but sadly your solution is not working for me... The attached document's jargon confuses me a bit as the dilettant I am. :-(
Though, it gave a nice clue... Hence, I found this link with a simpler way to do this (in my case, link to a specific part of a text in some other author's blog post without ID tags):
Share or link to quotes and text in Chrome
https://support.google.com/chrome/answer/10256233?hl=en-GB&co=GENIE.Platform%3DDesktop
To create a link that opens directly to highlighted text:
On your computer, open Chrome.
Go to a page with text that you want to share.
To highlight the text that you want to share, click and hold, then drag your mouse.
To open the context menu, right-click on the highlighted text.
Select Copy link to highlight.
If you can’t select this option, this feature may not work for the selected content.
Paste the link anywhere; for example, into an email or message thread.
Tip: To remove the highlight from the text in the linked content, right-click the highlighted text and select Remove highlight.
If you want to link to a specific part of a PDF file online, this solution also worked for me:
https://helpx.adobe.com/acrobat/kb/link-html-pdf-page-acrobat.html#:~:text=Open%20a%20PDF%20file%20to,end%20of%20the%20link's%20URL.
Just posting this in case someone is still lost as I was.
Cheers!
The AnchorMe addon from Firefox just solved this for me. Ctrl + double click on your desired destination and voilà.

HTML link to a certain point in a webpage - slight twist

Here's the use case: A user clicks on a link that opens a window displaying the contents of a text log. Easy enough. But is there a way of using POST, to open that text log to a certain location (i.e., search for a particular timestamp given in the post, and show the file at that specific location)?
(Assume I can't put html tags inside the text log -- it's a raw file).
Template of log:
+++ 2009/06/19 10:47:12.264 ACTION +++
+++ 2009/06/19 10:49:12.111 ACTION +++
So I want the page to load a specific timestamp.
Thanks,
Michael
Why can't you just have a php or perl or simlar script that processes the log file on the spot, and sticks in html anchors and calls it a day?
Doing on the spot processing would also allow you display a trimmed down copy of the log thats only relevant to the timespan around the event in question.
Since you can't modify the file, the only way would be to wrap it in a <frame> or an <iframe> and drive the searching and scrolling from JavaScript in the neighbouring/containing page.
Here's an example, which you can try out online at http://entrian.com/so-container.html
<html><head><script>
function go() {
// "line" is the <input> for which line to jump to; see the HTML.
var line = document.getElementById('line').value;
if (document.body.createTextRange) { // This is IE
var range = frames['log'].document.body.createTextRange();
if (range.findText(line)) {
range.select(); // Scroll the match into view and highlight it.
}
} else { // Non-IE. Tested in Firefox; YMMV on other browsers.
frames['log'].find(line); // Scroll the match into view and highlight it.
}
}
</script></head><body>
<input type='text' size='5' name='line' id='line' value='10'>
<button onclick='go()'>Go</button><br>
<iframe name='log' width='100' height='50' src='so-data.txt'>
<!-- so-data.txt contains the numbers 01-20 on separate lines -->
</body></html>
I've tested that in IE7 and FF3; I'd be surprised if it worked elsewhere without edits, but you never know your luck!
Obviously in your case you'd be driving the scrolling programmatically rather than via an <input> box, but you can see how it would work for you.
If you could put some tags around the file's text, then you could probably insert some javascript that would scroll the window after loading it.
Yes, but passing your parameters via a querystring would be a whole lot simpler.
To scroll to a certain position in the text file you will need to user javascript (overly complicated in my opinion) or add an html anchor tag.
If you were planning to post the raw text log in a window, you will also run into some difficulty as HTML will not recognize the newlines and run the log together into one blob.
have you tried
window.open ('log.txt');
window.scrollTo (0, window.scrollMaxY);
? From mozilla reference : https://developer.mozilla.org/en/DOM/window.scrollMaxY
Keep a 'living copy' of the log file that has been translated to HTML - every time the original file is modified (or simply every X seconds), check for and append the newest lines with HTML anchors applied to the HTML version.
A new feature was added to Chromium waaaaay back in 2020 that allows you to link to ANY location on any webpage.
At the time of this writing, it works for sure in Chrome and Opera but not yet in Firefox, Safari or Brave browser.
The trick is to add:
/#:~:text=
and follow the equal sign with the desired search text, replacing any spaces with %20. Example:
There is no ID near this location on the page
<div>IMPORTANT: Use Opera or Chrome to open above link</div>
For more information:
Linking to a specific part of a web page

Best Way to View Generated Source of Webpage?

I'm looking for a tool that will give me the proper generated source including DOM changes made by AJAX requests for input into W3's validator. I've tried the following methods:
Web Developer Toolbar - Generates invalid source according to the doc-type (e.g. it removes the self closing portion of tags). Loses the doctype portion of the page.
Firebug - Fixes potential flaws in the source (e.g. unclosed tags). Also loses doctype portion of tags and injects the console which itself is invalid HTML.
IE Developer Toolbar - Generates invalid source according to the doc-type (e.g. it makes all tags uppercase, against XHTML spec).
Highlight + View Selection Source - Frequently difficult to get the entire page, also excludes doc-type.
Is there any program or add-on out there that will give me the exact current version of the source, without fixing or changing it in some way? So far, Firebug seems the best, but I worry it may fix some of my mistakes.
Solution
It turns out there is no exact solution to what I wanted as Justin explained. The best solution seems to be to validate the source inside of Firebug's console, even though it will contain some errors caused by Firebug. I'd also like to thank Forgotten Semicolon for explaining why "View Generated Source" doesn't match the actual source. If I could mark 2 best answers, I would.
Justin is dead on. The key point here is that HTML is just a language for describing a document. Once the browser reads it, it's gone. Open tags, close tags, and formatting are all taken care of by the parser and then go away. Any tool that shows you HTML is generating it based on the contents of the document, so it will always be valid.
I had to explain this to another web developer once, and it took a little while for him to accept it.
You can try it for yourself in any JavaScript console:
el = document.createElement('div');
el.innerHTML = "<p>Some text<P>More text";
el.innerHTML; // <p>Some text</p><p>More text</p>
The un-closed tags and uppercase tag names are gone, because that HTML was parsed and discarded after the second line.
The right way to modify the document from JavaScript is with document methods (createElement, appendChild, setAttribute, etc.) and you'll observe that there's no reference to tags or HTML syntax in any of those functions. If you're using document.write, innerHTML, or other HTML-speaking calls to modify your pages, the only way to validate it is to catch what you're putting into them and validate that HTML separately.
That said, the simplest way to get at the HTML representation of the document is this:
document.documentElement.innerHTML
[updating in response to more details in the edited question]
The problem you're running into is that, once a page is modified by ajax requests, the current HTML exists only inside the browser's DOM-- there's no longer any independent source HTML that you can validate other than what you can pull out of the DOM.
As you've observed, IE's DOM stores tags in upper case, fixes up unclosed tags, and makes lots of other alterations to the HTML it got originally. This is because browsers are generally very good at taking HTML with problems (e.g. unclosed tags) and fixing up those problems to display something useful to the user. Once the HTML has been canonicalized by IE, the original source HTML is essentially lost from the DOM's perspective, as far as I know.
Firefox most likley makes fewer of these changes, so Firebug is probably your better bet.
A final (and more labor-intensive) option may work for pages with simple ajax alterations, e.g. fetching some HTML from the server and importing this into the page inside a particular element. In that case, you can use fiddler or similar tool to manually stitch together the original HTML with the Ajax HTML. This is probably more trouble than it's worth, and is error prone, but it's one more possibility.
[Original response here to the original question]
Fiddler (http://www.fiddlertool.com/) is a free, browser-independent tool which works very well to fetch the exact HTML received by a browser. It shows you exact bytes on the wire as well as decoded/unzipped/etc content which you can feed into any HTML analysis tool. It also shows headers, timings, HTTP status, and lots of other good stuff.
You can also use fiddler to copy and rebuild requests if you want to test how a server responds to slightly different headers.
Fiddler works as a proxy server, sitting in between your browser and the website, and logs traffic going both ways.
I know this is an old post, but I just found this piece of gold. This is old (2006), but still works with IE9. I personnally added a bookmark with this.
Just copy paste this in your browser's address bar:
javascript:void(window.open("javascript:document.open(\"text/plain\");document.write(opener.document.body.parentNode.outerHTML)"))
As for firefox, web developper tool bar does the job. I usually use this, but sometimes, some dirty 3rd party asp.net controls generates differents markups based on the user agent...
EDIT
As Bryan pointed in the comment, some browser remove the javascript: part when copy/pasting in url bar. I just tested and that's the case with IE10.
If you load the document in Chrome, the Developer|Elements view will show you the HTML as fiddled by your JS code. It's not directly HTML text and you have to open (unfold) any elements of interest, but you effectively get to inspect the generated HTML.
In the Web Developer Toolbar, have you tried the Tools -> Validate HTML or Tools -> Validate Local HTML options?
The Validate HTML option sends the url to the validator, which works well with publicly facing sites. The Validate Local HTML option sends the current page's HTML to the validator, which works well with pages behind a login, or those that aren't publicly accessible.
You may also want to try View Source Chart (also as FireFox add-on). An interesting note there:
Q. Why does View Source Chart change my XHTML tags to HTML tags?
A. It doesn't. The browser is making these changes, VSC merely displays what the browser has done with your code. Most common: self closing tags lose their closing slash (/). See this article on Rendered Source for more information (archive.org).
Using the Firefox Web Developer Toolbar (https://addons.mozilla.org/en-US/firefox/addon/60)
Just go to View Source -> View Generated Source
I use it all the time for the exact same thing.
I had the same problem, and I've found here a solution:
http://ubuntuincident.wordpress.com/2011/04/15/scraping-ajax-web-pages/
So, to use Crowbar, the tool from here:
http://simile.mit.edu/wiki/Crowbar (now (2015-12) 404s)
wayback machine link:
http://web.archive.org/web/20140421160451/http://simile.mit.edu/wiki/Crowbar
It gave me the faulty, invalid HTML.
This is an old question, and here's an old answer that has once worked flawlessly for me for many years, but doesn't any more, at least not as of January 2016:
The "Generated Source" bookmarklet from SquareFree does exactly what you want -- and, unlike the otherwise fine "old gold" from #Johnny5, displays as source code (rather than being rendered normally by the browser, at least in the case of Google Chrome on Mac):
https://www.squarefree.com/bookmarklets/webdevel.html#generated_source
Unfortunately, it behaves just like the "old gold" from #Johnny5: it does not show up as source code any more. Sorry.
In Firefox, just ctrl-a (select everything on the screen) then right click "View Selection Source". This captures any changes made by JavaScript to the DOM.
alert(document.documentElement.outerHTML);
Check out "View Rendered Source" chrome extension:
https://chrome.google.com/webstore/detail/view-rendered-source/ejgngohbdedoabanmclafpkoogegdpob/
Why not type this is the urlbar?
javascript:alert(document.body.innerHTML)
In the elements tab, right click the html node > copy > copy element - then paste into an editor.
As has been mentioned above, once the source has been converted into a DOM tree, the original source no longer exists in the browser. Any changes you make will be to the DOM, not the source.
However, you can parse the modified DOM back into HTML, letting you see the "generated source".
In Chrome, open the developer tools and click the elements tab.
Right click the HTML element.
Choose copy > copy element.
Paste into an editor.
You can now see the current DOM as an HTML page.
This is not the full DOM
Note that the DOM cannot be fully represented by an HTML document. This is because the DOM has many more properties than the HTML has attributes. However this will do a reasonable job.
I think IE dev tools (F12) has; View > Source > DOM (Page)
You would need to copy and paste the DOM and save it to send to the validator.
Only thing i found is the BetterSource extension for Safari this will show you the manipulated source of the document only downside is nothing remotely like it for Firefox
The below javascript code snippet will get you the complete ajax rendered HTML generated source. Browser independent one. Enjoy :)
function outerHTML(node){
// if IE, Chrome take the internal method otherwise build one as lower versions of firefox
//does not support element.outerHTML property
return node.outerHTML || (
function(n){
var div = document.createElement('div'), h;
div.appendChild( n.cloneNode(true) );
h = div.innerHTML;
div = null;
return h;
})(node);
}
var outerhtml = outerHTML(document.getElementsByTagName('html')[0]);
var node = document.doctype;
var doctypestring="";
if(node)
{
// IE8 and below does not have document.doctype and you will get null if you access it.
doctypestring = "<!DOCTYPE "
+ node.name
+ (node.publicId ? ' PUBLIC "' + node.publicId + '"' : '')
+ (!node.publicId && node.systemId ? ' SYSTEM' : '')
+ (node.systemId ? ' "' + node.systemId + '"' : '')
+ '>';
}
else
{
// for IE8 and below you can access doctype like this
doctypestring = document.all[0].text;
}
doctypestring +outerhtml ;
I was able to solve a similar issue by logging the results of the ajax call to the console. This was the html returned and I could easily see any issues that it had.
in my .done() function of my ajax call I added console.log(results) so I could see the html in the debugger console.
function GetReversals() {
$("#getReversalsLoadingButton").removeClass("d-none");
$("#getReversalsButton").addClass("d-none");
$.ajax({
url: '/Home/LookupReversals',
data: $("#LookupReversals").serialize(),
type: 'Post',
cache: false
}).done(function (result) {
$('#reversalResults').html(result);
console.log(result);
}).fail(function (jqXHR, textStatus, errorThrown) {
//alert("There was a problem getting results. Please try again. " + jqXHR.responseText + " | " + jqXHR.statusText);
$("#reversalResults").html("<div class='text-danger'>" + jqXHR.responseText + "</div>");
}).always(function () {
$("#getReversalsLoadingButton").addClass("d-none");
$("#getReversalsButton").removeClass("d-none");
});
}

sIFR 3 issue (IE) with BlockUI and UpdatePanel

I am experience an issue using sIFR 3, jQuery BlockUI and an UpdatePanel where the page refreshes and the SIFR font disappears.
In the Javascript file I use to handle the blocking and unblocking of the UI, I detect the partial postback and unblock the UI:
prm.add_endRequest(function() {
$.unblockUI(); });
If I re-run sIFR.replace() in this code block the font sIFR font is rendered, but # characters are replacing my page title (in the top of the browser window/tab). This seems to only happen in IE (go figure.) Each time I refresh the page using the LinkButton an extra # character is added, so my page title ends up looking like "#########". Any idea why this is happening?
Is there a specific sIFR.update() function I should be running instead? If I execute sIFR.redraw() or sIFR() I get javascript run time errors.
This is caused by a bug in IE:
This is a very peculiar bug in IE where for each Flash movie in the page the fragment identifier part of the URI (#foo) is repeated in the document title. It has been reported by Macromedia that this bug can be fixed by updating the VBScript engine the browser uses. However, for those users who still have the wrong engine sIFR contains a workaround.
http://wiki.novemberborn.net/sifr/Fragment+Identifier+Bug
sIFR 3 has a workaround but it doesn't kick in unless the page is loaded with a fragment identifier (window.location.hash != ""). In your case, I assume the page is loaded without the identifier, then you add one, and then you re-run replacements, reinvoking the bug.
You can patch r436 by opening (the compressed version of) sifr.js and replacing this.fix=c.ua.ieWin&&window.location.hash!="" by this.fix=c.ua.ieWin.