I recently learned that webmail clients like Gmail will do alterations on HTML emails, for example adding target="_blank" to <a> tags.
I've also discovered that other alterations happen as well. When I send an HTML email to Gmail (and possibly other web mail clients) from my PHP script, variable values included in the URL of any links are being stripped out. So, for example, this is the value I'm setting in my PHP code:
$mailContent = '<p><a target="_blank" href="https://example.com/confirmation.html?verification=x1x1x1x1x1x1x1x&email=yyyy#email.com">click here to go to the web site and activate your account!</a></p>';
But when the email is received in Gmail, the HTML code comes out like this:
<p><a target="_blank" href="https://example.com/confirmation.html?verification=&email=">click here to go to the web site and activate your account!</a></p>
The values x1x1x1x1x1x1x1x and yyyy#email.com have been stripped out from within the <a> tag.
How do I protect the values of the variables that I want to pass to the URL so that Gmail won't remove them?
Click View original/source on the message in Gmail to see if the URLs looks like they should then. If so you know that the problem is how Gmail is formatting the message for your viewing. If it's mutilated even in the source I was wondering if there's anything in your webpage/php/CMS (do you use one) that changes the code.
You should try URL-encoding as #Crisp said. Here's the W3 reference.
Emailing in html uses Quoted-printable Encoding. The problem with your $mailContent is that the "=" must be represented by =3D
Try adding this:
$mailContent = quoted_printable_encode($mailContent);
This may not be the perfect answer, but if your application allows for it, I have used URL shorteners a number of times.
http://goo.gl/ is my preferred because the API is super easy to implement and google is very fast. I have a function in a class and I just run my url through it and send the return wherever I need it to be.
Another non-perfect answer here but, my problem was that I was including an http url in the html body and apparently is not valid so I changed them to https. This was on a dev environment so no problem on production.
Here is more info about this:
Any URL's in the body of the mail which lead to insecure sites may also need to be removed. Use https://transparencyreport.google.com/safe-browsing/search to validate these links.. All links should be correctly prefixed with "https". https://en.wikipedia.org/wiki/HTTPS Google seem to be rejecting "http". Sometimes, but not always, removing links from any signature can help.
I've implemented the like button on my WP blog, but for some reason some of them (not all of them) are interpreted as being the same button. If I press like, I will also like the ones that is interpreted as the same. I can't figure out why. There are several other problems with what is shared on Facebook, but I think those problems are connected to this one.
It worked great for a few days, then I started getting an error each time I pressed the like button. After fiddling with the og:type value the error disappeared, but instead now I get this strange behaviour.
My implementation is so simple, I can't really think of any causes:
<div class="fb-like"><fb:like href="<?php the_permalink();?>" show_faces="true" width="600" font="arial"></fb:like></div>
I've found that the behaviour changes depending on what og:type I define in the header section, but with no value producing the correct result.
the blog can be seen at http://blog.parkov.dk/ (in Danish, though).
Anyone has experience with this?
Remove the href parameter and instead use the Open Graph meta tags. I see that you are using them but some required tags are missing:
og:title
og:url
IMPORTANT NOTE:
For the homepage use blog as og:type!
This is something of a follow-up question to my question here. You can find the HTML source in a text file here.
When I load that page in IE8, I get the "Done, but with errors on page." message in my status bar. The detail view shows
Expected identifier
sms Line: 147
Code: 0 Char: 67
and I see absolutely no problems anywhere near there. In IE8, the page is still behaving erratically w/r/t the randomly losing focus as mentioned in my other question.
When I load the same exact page in Firefox (using Firebug) the console shows no errors and the page works perfectly. Any thoughts on what's going on here? This is driving me nuts and making me want to give up on even trying to write an IE friendly page.
Edit: Thanks for all the comments! This page is written as a JSP, so I edit in Eclipse. I found an Eclipse warning about the onblur event for the username field. I switched it from
onblur="alert(document.activeElement + ' class:' + document.activeElement.class)"
to
onblur="alert(document.activeElement)"
and that made the bizarre IE page error vanish. I had been trying to give more info (namely, its CSS class) about specifically which element is stealing focus - to my own detriment, apparently, since Javascript was interpreting the '.class' part in the Java(script) sense there is no class property (I should have been using className).
And, no, the page doesn't validate. But the errors were mostly/all ones that just didn't make sense to me, such as
Line 14, Column 41: Attribute "LANGUAGE" is not a valid attribute. Did you mean "language"?
But I'm still stuck trying to figure out why, as I enter text in the username & password fields, focus randomly switches to a div (working on figuring out which div currently).
Edit 2: It's the div between the two "global nav" comments, at the very top of the body. Still no idea why it's happening, though.
The problem appears to be the line
onBlur="alert(document.activeElement + ' class:' + document.activeElement.class)"
when you take off the ".class" it loads without issue. Are you sure ".class" is valid?
Does your HTML validate?
I agree, IE does a terrible job giving developers information about page errors. I only support IE on the principle that users shouldn't have to download twenty-odd browsers to go to their favorite websites. Web developers have a responsibility to make it "just work". Browser developers have a responsibility to communicate with each other and conform to standards.
Run your javascript through JSLint. You probably have a missing semicolon somewhere or a comma at the end of an object property that shouldn't be there. Firefox is more forgiving than IE when it comes to those types of syntax errors.
Edit: The inline js in your page seems to be OK. Check the contents of qm_scripts.js.
When I remove the .class from document.activeElement.class the error goes away.
The real issue is that you need to be able to debug your JS in IE 8, correct? There is a tool for that! :)
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
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");
});
}