I am using Knockout.js, and the most important part of the error message is (nowadays) often hidden under the <omitted> part. I tried hovering over, and clicking a lot of stuff, but I can't find a way to see the full message. Does anyone have a tip?
Thanks in advance!
PS: I'm looking for a fix within the Chrome settings. So without cluttering my code with extra window.onerror stuff or otherwise. I don't want to clutter my code just because the Chrome development team thought it was a good idea to omit debug text :S
For a code hack, see this answer: https://stackoverflow.com/a/22218280/647845
Here's a little bit of code that will output the whole error message:
window.onerror = function (errorMsg, url, lineNumber, columnNumber, errorObject) {
if (errorObject && /<omitted>/.test(errorMsg)) {
console.error('Full exception message: ' + errorObject.message);
}
}
You can execute this in the development console in Chrome, so it doesn't have to be in the actual code of your web page.
Use Firefox. And vote up for this issue in the meantime:
https://code.google.com/p/chromium/issues/detail?id=331971
Related
With this simple anchor link & anchor target - originally defined by Tim Berners-Lee as a HTML Fragment Identifier - is there a way to stop a false JavaScript error from appearing in Aurelia?
HTML:
In Page Link
...
<a name="in-page-link">The link scrolls/jumps here</a>
JavaScript Router Error #1 (Not a real error):
Error: Route not found: /in-page-link
That's a false positive error. Of course it's not found! It's an in page link! It isn't a route! That JS "error" isn't a real error.
Is there a way to suppress that error, without having to over-engineer a JavaScript solution - to measure scroll heights & adjust the page offset - simply get around the flawed Node.js design paradigm, where routers break a basic HTML feature to create regex paths AKA: routes? Why do I need to invent a JS fix for something a framework broke? If you break it, you fix it, right?
I've tried using Aurelia's router-ignore idea, but it doesn't work for links which start with hash tags. This similar SO answer doesn't work (& the 2nd line of the OP question was incorrect): How do I keep on the same page by clicking on internal anchor links, using Aurelia?
Is there a router configuration BYPASS feature, which won't try to re-route the URL to another location?
I've tried using nav: false in the router configuration, but it wants a moduleId. There isn't a moduleId for an in page link target.
With a basic router configuration JSON block like this...
{
name: 'no_redirect',
route: ['in-page-link'],
nav: false
}
... how do I stop either the first JavaScript error (up above) or this additional JavaScript error from appearing, considering in page links won't have nor need to use these: moduleId, redirect, navigation nor viewPort? It's just an in page link.
JavaScript Router Error #2:
Uncaught (in promise) Error: Invalid Route Config for "in-page-link": You must specify a "moduleId:", "redirect:", "navigationStrategy:", or "viewPorts:".
I'm trying to make this HTML link work, without having Aurelia throw false JavaScript errors into the console.log. Is there an easy way to do that?
In Page Link
...
<a name="in-page-link">The link scrolls/jumps here</a>
I figured out a solution for my problem!
I tried getting it to work with anchor links & router-ignore, but neither of those worked out for the site that I'm building. Perhaps it's using an older version of Aurelia, which doesn't have that router-ignore feature yet? Maybe. I don't know. I didn't check.
There is an open bug for my 1st JavaScript error on GitHub. It also has an interesting router configuration in it, which would address my 2nd JavaScript error.
I've discovered a faster & simpler work-around, which other Aurelia developers might like!
I reached out to Rob Eisenberg, who was kind enough to point me to his discord.aurelia.io site. While searching it, I found an interesting work-around idea! After exploring it & the related code examples, I was able to get the 1st false JavaScript error to disappear... without having to over-engineer any browser pixel measuring logic! I really didn't want to have to write any JS scrollbar math again, using clientOffset values. Here is a good example of measuring the scrollbar height.
I have repeatedly written code like that in the past, but I wanted to avoid having to reinvent that wheel... yet again! I really wanted to figure out another way to fix this basic snag, without having to write any custom scrollbar math logic because it felt like I was writing too much code to fix a bug in the underlying framework. Other frameworks, besides Aurelia also suffer from hijacking the '#' in the URL to create routes. It appears to be a recurring issue in the Node.js community.
This fast work-around for Aurelia is super small, fast & easy to implement. Perhaps someone will enjoy this!
Change <a href="#in-page-link"> to <div class="link" click.trigger="jumpDown()">.
Add a method into the behind-the-scenes matching JavaScript file, which sets a boolean:
jumpDown () {
this.linkClicked = true;
}
Change <a name="in-page-link"> to <button class="btn" focus.bind="linkClicked">.
Use CSS to style the link, plus add a cursor: pointer; property & hide any button styles, as desired.
So the final code would look like this:
HTML:
<div class="link" click.trigger="jumpDown()">In Page Link</div>
...
<button class="btn" focus.bind="linkClicked">The link scrolls/jumps here</button>
JavaScript:
jumpDown () {
this.linkClicked = true;
}
CSS:
.btn {
/* Style as desired. */
}
.link {
color: #0000FF;
cursor: pointer;
text-decoration: underline;
}
Then the original JavaScript error #1 vanishes! The link click still works! No additional router configuration is needed! Web developers look like web rockstars! The quality assurance team is happy! Problem solved!
I wrote a Firefox extension that reads the clipboard and if it has some PEM certificate, it will print it's details in a new tab. I'm trying to port to Chrome. It does not work. What am I doing wrong?
I asked for the clipboardRead in manifest.json and I run this in background script and it works fine in Firefox.
navigator.clipboard.readText().then(function (textFromClipboard) {
//do stuff with textFromClipboard
});
This fails in Chrome with "Failed to execute 'readText' on 'Clipboard': Illegal invocation". What am I doing wrong? How can I make this work in Chrome also? Most answers involve creating an input, getting focus, executing paste. That is really complicated, I hope I don't have to do this. It works really well in Firefox, why is it complicated in Chrome?
You can use #bumble/clipboard. It is an npm library for Chrome extensions that emulates the Clipboard API.
It doesn't require user interaction, and works in a background script. It only requires clipboardRead or clipboardWrite permissions.
import { clipboard } from '#bumble/clipboard'
// Read text from the clipboard, or "paste"
clipboard.readText()
.then((text) => {
console.log('clipboard contents', text)
})
// Write text to the clipboard, or "copy"
clipboard.writeText('write this to the clipboard')
.then((text) => {
console.log(text, 'was written to the clipboard')
})
Disclosure: I wrote this library for myself to solve the same problems that #ddreian mentioned. It is a non-blocking Promise based solution that uses document.execCommand under the hood.
I noticed that whenever you download a PDF in Chrome, it consistently makes two requests, and then cancels one of them. This is causing the request to be registered twice in my Web app, which don't want. Is there a way to get Chrome to only make one request for PDFs?
I've researched this topic quite a bit now, and I have not found a sufficient answer. Closely-related answers suggest that the problem is that Chrome is looking for a favicon, but the network tab shows that it is actually making the same request twice, and then canceling the second request.
Is there a way to prevent Chrome from making the second request?
Below is a link to a random PDF file that I found through Google which when clicked should demonstrates the behavior. I would've posted a picture of my network tab in devtools but this is my first post on Stack Overflow, and the site is prohibiting me from uploading a picture.
https://www.adobe.com/enterprise/accessibility/pdfs/acro6_pg_ue.pdf
It looks like a bug in Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=587709
The problem is that Chrome, when it loads an iframe that returns a PDF stream, writes an "embed" tag inside that iframe which again contains the same URL as the iframe. This triggers a request for that URL again, but Chrome immediately cancels it. (see the network tab)
But by that time, the damage is done.
We have the same issue here, and it does not occur in Firefox or IE.
We're still looking for a good solution to this problem.
I'm still trying to find a proper solution but as a partial "fix" for now you could have two options
1) set the content disposition to "attachment" in the header
setting that to "inline" cause chrome to run a second cancelled call
so for example you can do something like that (nodejs resp in example)
res.writeHead(200, {
'Content-Type' : 'application/pdf',
'Access-Control-Allow-Origin' : '*',
'Content-Disposition' : 'attachment; filename=print.pdf'
});
unfortunately this solution will force the browser to download the pdf straight away instead of rendering it inline and that's not maybe desiderable
2) adding "expires" in the headers
this solution will always fire a second cancelled call but it's ignored by the server
so for example you can do something like that (nodejs resp in example)
res.writeHead(200, {
'Content-Type' : 'application/pdf',
'Access-Control-Allow-Origin' : '*',
'Content-Disposition' : 'inline; filename=print.pdf',
'Expires' : new Date(new Date().getTime() + (60000))
});
I had the same problem in an iframe. I turned of the PDF Viewer extension and the problem disappeared. I'm thinking the extension downloads the file twice. The first time to get the size, the second time to download with a progress bar (using the size gathered in the first request)
I've tried the other solutions and none worked for me, I'm a little late, I know, but just for the record, I solved this in the following manner:
Adding the download attribute:
In my case I was using a form, so it goes like this:
<form action="/package.zip" method="POST" download>
This worked on Brave and Safari, which previously showed the same problem, I think it will work for Chrome.
With my case, problem wasn't browser related. I've noticed our scrollbar plugin's (OverlayScrollbars) DOM manipulations reloads embedded pdf data and calls controller more than once due to on plugin's construct or destroy events. After I've initialized scrollbar before DOM is ready, problem is solved.
I've recently been contributing to the Enhanced Steam extension and I've found that a link fetched with chrome.extension.getURL simply opens about:blank and not the link described.
I do not believe it's actually a problem with the extension, but rather a problem in chrome. The link it supplies is valid (chrome-extension://pimjhgjngccknempdnehdeaihcjbajod/options.html) and navigating directly works correctly.
I tried chrome.tabs.create, but found that I am not allowed to use it due to the script modifying pre-existing content.
Any help or work arounds would be appreciated.
I put all my required files into "web_accessible_resources", it solved my problem. See this in #4 https://bugs.chromium.org/p/chromium/issues/detail?id=310870#c4
It is Chrome's previous problem which is not secure. In build 31.0.1650.57, Chrome fixed this which is to force to put required files in "web_accessible_resources". In Chrome extension, lots of samples don't use "web_accessible_resources", those are the bugs, those samples will have this "chrome-extension:// links open about:blank" problem in build 31.0.1650.57.
Actually my chrome extension MarkView was facing this issue and I had to update its manifest.json to make it work for this Chrome update. By the way, MarkView is tool to read and write Awesome Markdown Files, it provides features including Content Outline, Sortable Tables and code block syntax highlight with line number.
Looks like a bug in Chrome to me. If you don't have too many pages like this to change then could you try using message passing to pass the page you want to open to the background page? Then use either window.open or chrome.tabs.create within the background page. Example code shown below:
//CONTENT SCRIPT
chrome.runtime.sendMessage({greeting: "OpenPage", filename:"somepage.html", querystring:"?aValue="+someVal}, function(response) {});
Then in your Background page
//BACKGROUND PAGE
chrome.runtime.onMessage.addListener(
function(request, sender, sendResponse) {
if (request.greeting == "OpenPage"){
open_page(request.filename, request.querystring)
}
});
function open_page(filename, querystring){
var pageUrl = chrome.extension.getURL(filename)+querystring;
chrome.tabs.create({'url': pageUrl }, function(tab) {
// Tab opened.
});
}
I am using javascript and ajax the most in my project source. All functions are working well in firefox. But some of them are not working in ie 6 and 7 browsers. Mainly Delete is not working for any page in my project. I dont know how to resolve those bugs. And dont know how to see errors in ie browsers.. So Plz help me to resolve this issue. Thanx in advance
Download and install Internet Explorer Developer Toolbar and test your pages. Since you said you are using AJAX I think error can be javascript related.
In IE javascript errors are shown on the left hand side of the status bar (bottom).
You can also make IE show notification about error message by going to
Tools-> Internet Options -> Advanced
[Tab]
and choose "Display a notification about every script error".
Please post more info about your issue.
What is happening when you call the "delete" function?
What is it supposed to do?
Tools -> Internet Options -> Advanced -> Enable Script debugging.
create try-catch statements in your code, and alert or print error messages recieved in the catch clause:
try {
somethingThatDoesntWork();
} catch(e) {
alert(e.message);
}
Using this with the other tips on getting some proper debugger running should help quite a lot (: