i'm struggling with the classic HTML input of type file. I was using it on my angular application and i had freeze sometimes, the whole browser became unresponsive, and the only thing that works is the scroll.
You can't click any buttons, select any text or even change tab on the browser for about 5 seconds. I tried a lot of different file type and sizes and it doesn't change any of this, it even freeze sometimes when i don't select any file in the explorer and i click the close button directly.
So I thought it was my implementation that was bad and i went to the Mozilla developper website where you have an example and I have exactly the same behaviour. I also tried to take only the HTML from the Mozilla website and put it alone on a .html file and again, same behaviour.
This does not occur 100% of the time, but I would argue that on my end it does it about 60/70 % of the times.
I tried it on chrome and Firefox (both up to date), on multiple computer (all running Windows though) and i have the same behaviour on all of them.
I don't have any error or anyting in the consoles.
I don't know what to do with this, i'm pretty sure it can't be the file's input on the whole web that are bugged, but i tried a lot of various things with always the same results. Should i report it somewhere? ( if so, where? ) Or what would you suggest to do to investigate this further?
I couldn't find anyone discussing this issue on the internet apart for this thread that had no solution, they also say in this thread that the bug is not reproducible in Edge, but i just tried and it does the same thing.
Thanks for reading me and for any help about this.
Chrome freezes for few seconds when after any use of file field.
It was because I had a shortcut in "Quick Access" menu in windows explorer. This shortcut has been linked with a folder shared by network. I've removed this shortcut and everything is good now.
Same here, I have a mapped network drive that is not responding, this make a 5 seconds delay. After unmapping the drive, no more delay. The delay is the same in firefox or chrome.
Same here, if you want to remove it, on Windows 10, click on the icon Quick access (blue star), then right click on the dead link appearing in the "Frequent folders" panel on the right panel and choose "Unpin/Remove from Quick access". There should be no error message.
Related
I have a small database project where users can attach files to records. Mostly pdf and word docs. I am using the attachment type fields that access provides because I want to get more familiar with them. I have a continuous form that shows the attachment field using the Picture/Symbol view option. Most of the time, but strangely not always, the attachment symbol shows this black background behind its symbol. The black background does not cover the whole field but rather only the picture for the attachment type (Word, PDF etc.). The field itself is set to transparent, which is neccesary for my row highlighting to work. Does anyone know why this is happening? Is it a bug? Some way to fix it? It had worked when I had first set it up but upon restarting my computer and reopening the project they turned black and are now stuck that way. I removed them later for some reason and re-did the whole thing, upon which it seemingly worked but after restarting it went black again. There is no difference between using the view settings Picture/Symbol and Symbol.
Visual Aid:
Update 1:
The black backgrounds are seemingly random. I set the view option to Paperclip, restarted access, then set them to Picture/Symbol again and now I get this:
Closing and opening the file appears to turn the backgrounds black. Changing the view type back and forth inbetween can fix some, but not always.... I'm really not sure what's going on.
Update 2:
The issue is seemingly not affected by transparancy settings. Changing the Background color of the field has no impact either. The issue also persists when making a new form from scratch and adding the Attachment type field to it. It also carries over from one pc to another, so unless both have the same issue in their windows installation I don't think that is the root cause either. Compress & Repair did not help. I am only using one attached file per record.
Update 3:
I have had no luck consistently reproducing the issue. Most of the time, about 80% of it I am estimating, the issue persists. Some days, when launching access, the issue is resolved partially for either the word icon, or the pdf icon. On some days the issue is resolved for all icons as in the picture below. Almost always, after closing and opening access, the issue will immediately reappear for all icons. Closing and opening the form only and keeping the file open is fine, the issue stays resolved. Really not sure how to go about this.
My Access version:
Version 2205 Build 16.0.15225.20028
My Windows install:
Microsoft Windows 10 Pro
10.0.19044 Build 19044
So, updated to windows 11 and the issue is solved. No idea what was wrong exactly but it turns out it was related to the windows install. So, some kind of a bug in Win 10 is my guess, since it was happening on two different machines both running win 10.
I can't find anybody facing the same problem as mine.
Every time I click an image on google image, suddenly the whole page disappear, but I'm still able to click things just like everything is still there.
I already turn off all extension, use incognito mode, after finally I try to use inspect element, and found attribute stating "Opacity: 0" on the body. And after unchecking the box (Quick disable attribute in inspect element chrome) everything shows up again.
I'm so confused on why this is happening.
Does anyone have ever facing the same problem?
Or how do I fix it?
It's so frustrating, because I have to refresh the page, every time I click on an image, or switch between images
so I was having this one. in the end, it was a virus.
In my case, it was showing an AD screen on the main google page, and in the sources>gstatic.com it had a different source which also was in a [unknown] source.
dug a bit up and discover some adware was using gstatic as a proxy to show ads on all browsers.
I solved it by running malwarebytes, it found it pretty quickly and solved it for me.
Posting this here because I'm hoping it helps people who search for this issue in the future.
part of the log
On the iPhone's Instagram app browser(in app) if you open a website that includes html inputs of any type, something strange happens.
In the beginning everything is working, but once you tap an input and type something ( and the keyboard is opened), after you close the keyboard you can't click on anything anymore because all buttons/inputs/elements are clickable in a different location than where they showed ( button is showed in the original 100px location but click events are now on 50px).
It looks like after the keyboard opens the whole location calculation is shifted up(because the keyboard pushes the whole body up)
How to even begin to debug such thing ?
Honestly, I've been there. There is no way to debug the in-app browser (you can try on an iphone device mirroring with Chrome in MAC, but you will eventually fail), but I've tried without success.
It turned out that after digging around with similar issues, there was a caching issue and some disabled features with WP ENGINE from my client. They were able to fix it by allowing some parameters on nginx settings and then the In App browser wasn't stucked anymore.
I know every issue is different, but at this time, I haven't found a way to debug the In - App browser.
I can't speak to iOS specifically, but there definitely are ways to remote debug things.
My go-to for stuff like this (speaking from experience of browsers on gaming consoles) is Weinre: https://people.apache.org/~pmuellr/weinre/docs/latest/Home.html You get something similar to Chrome Developer Tools, but it works over a Socket.IO connection.
Another tool I like to use is Fiddler. While it won't help you with your DOM issues, if you ever need to debug network stuff on oddball devices, it's perfect. It serves as a proxy server and can intercept all your connections, including HTTPS. https://www.telerik.com/fiddler
Turns out, that it's a fixed position and it's not supported, which means when keyboard is closed, the system will push back the whole view but click events stay up (because it's being pushed up when you open a keyboard).
So instead of make it an absolute modal, which has it's own problem, we keep it fixed, BUT, we do the pushing up/down by our own.
We could just push the screen back down on input unfocused, but if user click the next field you get unwanted behavior, so we create a delay based machine like so :
var isfocused=0;
var focusTimer=0;
$("input").blur(function() {
isfocused=0;
focusTimer = setTimeout(focusDone, 150);
});
$("input").focus(function(){
isfocused=1;
});
function focusDone(){
if(isfocused===0)
$(window).scrollTop(0,0);
clearTimeout(focusTimer);
}
This works great on social browsers, with fixed positioned modals that has inputs inside them.
When a site gets stuck in chrome with the 'loading www.site.com' status, Is there anyway to know which of the elements on the DOM is delaying the load? for example, it can be an external js file or image that is taking long time to load. I tried using the network tab in the DeveloperTools, but it only shows the elements already loaded and the time they took. I couldn't find a way to see which element is stuck.
I found a way that I'm not sure it works in all cases, but it did for me. I used the Timeline tab (now shown in the Performance tab), it's one of the tabs in Chrome Dev Tools.
Open Chrome Developer tools (F12 or CMD + Alt + I in Mac) and click the Performance tab
Make sure you drag the grey timeline bar all the way to the right, you want to see the most recent section of events so you can find what's getting stuck:
Check just down below the records sidebar. If you don't see this like in the capture below, try toggling the icons, there are different view modes. Now, going all the way down I found these. It doesn't look like that's going well. Obviously some kind of infinite loop in some random code:
I couldn't find out if it was an extension itself or some other bit of code. Clicking through I only could find // Copyright 2014 The Chromium Authors. All rights reserved..
Checking in Incognito mode clear of extensions, the website loads just fine.
I'd also advise to check the Console tab to see if there are were any errors that might cause the infinite loading thing. You'll often find clues there.
I am referring to the save feature in the 'Sources' panel of the Chrome Dev Tools. I have been using this feature for a long time in the stable release of Chrome, but after installing the build from the developer channel, I notice that once I have saved the file the first time, Chrome no longer prompts me to save and just does it automatically after every change I make.
This is quite a pain, as I make a lot of changes experimentally in the dev tools whilst debugging which I don't wish to save, I would like Chrome to save the file only when I explicitly tell it to.
Does anyone know if there is a way to disable this automatic CSS saving?
(Apologies for no screenshot, my PrtScn key seemingly won't operate when I am in a context menu)
Update:
I have reverted to the current stable build, 27.0.1453.93, and the behaviour appears to be the same.
I am having the same problem, I can only offer workarounds: use another browser, such as Firefox, for doing tests!
Alternatively you could launch another instance of Chrome with a different profile. You could also launch a Chrome "Incognito Window", it seems to not apply the filesystem mappings.
I normally use an Incognito Window or inline styles to test changes.
Alas, I learned after reading a post by Google's dev relations person
that the automatic save cannot be disabled and it seems that's the way
it's going to stay.
html5rocks.com/en/tutorials/developertools/revolutions2013
– tommypyatt Feb 21 '14 at 14:22
While not solving the issue directly, it is a decent work around:
In Chrome, in the css inspector you can click and hold the + button, then choose to add your changes to the inspector-stylesheet. It's not as convenient as directly editing in your css-selectors, but what you write will all be in inspector-stylesheet.css, so not saved to your project. Then when you are happy with your changes, you can manually put them in to your css.