Certain character combinations are being rendered in the Microsoft Edge browser as 'undefined'. For example, in the link below, the teline of text:
I believe "Pilot" line is giving error message
is showing as:
I believe "Piloundefined line is giving error message
http://www.mychevybolt.com/forum/viewtopic.php?f=12&t=158
And on this page, the line of text:
The Bolt EV is being assembled at the General Motors Orion Assembly Plant in Township, Michigan.
is showing as:
The Bolt EV is being assembled at the General Motors Orion Assembly Plant in Townshundefined, Michigan.
http://www.mychevybolt.com/forum/viewtopic.php?f=10&t=162
There doesn't seem to be much rhyme or reason to when or why it happens. I've played with charset and can't seem to make it change.
It doesn't happen in any other browsers including IE11
After contacting Microsoft Support, they gave me the basis 'clear the cache' line. And surprisingly it worked! The problem re-appears every week or so and then I clear the cache again and it's temporarily fixed.
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'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.
I'm digging into MS Internet explorer 11 and mshtml.dll, lets be fast & clear : I'm investigating the "CTitleElement" class of "mshtml.dll" on windows 8.1, I want to set breakpoints on some functions in "CTitleElement" class to see what's going on inside this class (e.g : creating title element, getting title, setting title, getting title's length, etc ...)
I used windbg to attach the IE process, and here's what I did to set breakpoints :
0:013> bp MSHTML!CTitleElement::GetTitle
0:013> bp MSHTML!CTitleElement::SetTitle
0:013> bp MSHTML!CTitleElement::s_StringTable
0:013> bp MSHTML!CTitleElement::CreateElement
0:013> bp MSHTML!CTitleElement::TitleLength
and then running into IE with "g" command & opening the following simple html file :
<html>
<title>Hello There!</title>
</html>
but unfortunately, I did not get the desirable result, the debugger did not hit the breakpoints .
As I noticed, it's an unstable situation, because : "sometimes it got hit & sometimes not!"
I was think of ASLR and the type of breakpoint I just set ("bp"), disabled ASLR by installing EMET & disabling all memory protections, but I still unable to get the result in a reliable manner .
Any suggestion to solve this problem?
regards.
I don't think ASLR has got anything to do here. You are setting the break points using function names and not addresses. The addresses can change but the function names would still remain the same :)
to ensure that you do not miss out because of the child processes created by IE (as mentioned by Sesa)
Launch windbg.
From the file menu choose "Open Executable" OR Ctrl+E.
give the path of iexplorer.
make sure you have option "Debug Child Processes also" checked.
make sure you have the symbols correctly loaded.
To ensure your break-points persist across debugging sessions use "bu" instead of bp.
check that all break-points show up everytime using "bl"
I'm just speculating what is going on. Perhaps when you first load the page in IE it fully renders it. Next time, the page may not be fully rendered because the result of previous run used and an other code path is executed that doesn't hit your breakpoint.
Did you try force refresh Ctrl+F5?
Today I updated to Chrome 32 on Ubuntu 12.04, but tab title can't display Asian characters correctly, it displays typo instead. It works fine on Windows.
I've fired a bug for chromium project, however I still want to know if this is just for me or a common problem.
When I type "search" in Google, tab title shows:
When I type "検索", it shows:.
Can anyone reproduce this? In fact, I would love to fix this by myself but I may need some help on where I can find the code related to displaying tab title, the whole chromium code repository is just too big...
I currently have a webpage serving up phone numbers, some of these phone numbers have extensions so I have written the HTML like this:
+44-1234-56788 / <a href="tel:+44-1234-567;ext=99">+44-1234-56799</a
When I hit this page in my Android browser and tap one of the phone numbers, it loads up in my phone dialer (UK Samsung Galaxy s2 stock) as:
+44-1234-567;ext=88
which I don't think is correct. Surely it should omit the ;ext= word.
Have I misread the RFC for implementing tel?
Seems the proper way to do it is use a comma:
+44-1234-567 ext.88
Just tested with iPhone and Android OS 2.1. Using ;ext=88 converts the ext bit into a number that is dialed with the extension (so it dials something like 35888 instead of 88).
Comment for How do I include extensions in the tel: URI?
As of June 2021 the RFC3966 ;ext= syntax still isn't implemented by Android, and it's inelegantly implemented by iOS.
Using ;ext=123 as an example:
Android: after the call connects a modal window appears asking Send the following tones? 396123 with No and Yes buttons. "Send the following tones?" is a precise technical description of what will happen if the user taps Yes, but it is probably not the best wording for the average user.
Android converts ;ext=123 into 396123 because it treats the letters the same way as if you were dialing something like 1-800-FLOWERS, and this is a broken implementation of the syntax.
iOS provides an option to the left of the Disconnect button that says Dial “ext=…”. When you tap on this "button" it will dial the extension number. This is inelegant and has bad usability because the "button" doesn't look like a button — it's just plain text — and because you can't see the extension number.
In addition, when you first tap on a phone link in iOS it presents a button at the bottom of the screen which partially rewrites the phone number into a local format, but which also preserves most of the ;ext= syntax, e.g. Call +1 (555) 555-5555;ext123. This is also inelegant, and it's ugly besides.
If you instead use just a ; which is supposed to mean "wait," as in "wait until the auto attendant message ends and then automatically dial the extension":
iOS: tapping the link displays a button stating Call +1 (555) 555-5555;123 which is slightly less ugly than the button described above.
iOs provides the same extension-dialing "button" described above except the extension number is visible, e.g. Dial “123”. It still has the other usability problems.
iOS does not automatically dial the extension after the message ends.
Android: after the call connects a modal window appears asking Send the following tones? 123 with No and Yes buttons.
Android does not automatically dial the extension after the message ends.
So for now, as of June 2021 it seems that the only way to include extensions in tel: links that will actually work is to use either ; for "wait" or , for "pause":
555-555-5555 ext. 123 — this will provide a UI component which the user can invoke to dial the extension. The usability of the UI component depends on the OS; neither are great, but Android's is arguably better.
555-555-5555 ext. 123 — this will automatically dial the extension a couple seconds after the call connects. Note: This mechanism will not work with voicemail systems that don't accept user input until the auto attendant message ends.
According to the documentation, you can add what you want like so 12345678;ext=123
See RFC 3966
In all the examples I saw, the value of ext is contained in the full number. So try including 88 in the href value:
+44-1234-56788
For those still wondering about this problem: I've found it best to use this format:
<a href="tel:+13235798328;22">
Standards at thenewcode from 3 months ago suggest using a microdata pause.
<a href="tel:+13235798328p22">
Related:
Different standards persist across different external platforms and may change the processing of URIs. Click to call
features on Google Developers docs do not specify
Example:
Office's Skype uses x to represent extension within skype.
I feel like this is kind of a cop-out answer, but if this is not implemented consistently across devices yet, probably best to just not include the extension and let people dial it by hand:
+44-1234-567 ext. 88
or
+44-1234-567 ext. 88
Better to make the user do more work than to send 1/2 your users to the wrong extension.
I don't get the answers to this question - I think the're wrong. The correct link would look like this:
+44-1234-567 ext. 88