Chrome 87
In Chrome DevTools, there should be a bottom bar for switching message encoding (binary hex view, text, or base64), but now I can't find it in my Chrome, and all messages are automatically base64-encoded (they should be binary messages and I want them to be displayed in Hex). How can I solve this?
enter image description here
The issue appears to be a bug in Chrome 87. According to the latest comment, the issue was fixed in Chrome 89.
Related
We have a catalog on our college website.
It may be found here:
https://www.southark.edu/admissions/resources/course-catalog
The links going down the left side of the page point to specific pages within the catalog.
For example:
https://www.southark.edu/images/catalogs/2021-2022/2021-2022_SouthArk_Catalog_FINAL.pdf#page=100
But when clicked, Chrome truncates the last portion of the url (in this case, #page=100), and it displays the first page of the catalog, not the intended page.
This happens in Chrome, but not Firefox.
It has worked in Chrome for years, but now it does not.
Any idea why Chrome is doing this and what kind of workaround I might be able to do?
P.S. I just tested it in Safari on my iPhone and it is doing it on there as well.
Thanks,
Charley
I discovered that it is due to the Chrome PDF extension. If I turn it off, it operates as it should.
I have lately been finding that certain hyperlinks and submit buttons fail to work in Firefox, but never in Chrome. These are links that worked before, then they fail, and later they may work again. I never see this behavior in Chrome.
For example this bookmark link:
<div class="z_01">Paragraph text here. <span class="blank"><img src="images\corner-right-up.svg" alt="Top"></span></div><br><br>
I have also had the same problem with form submit buttons that work not at all of just sporadically in Firefox.
On some links, the cursor will change to a hand on the left side of the link (or button) but not on the right side.
It’s not due to a Firefox add-on because I’m working in Firefox Developer Edition and I have no add-ons installed on that version.
I’m in Firefox Developer Edition 69, but the same problem occurs in Firefox 67 and 68. It does not occur in Chrome 64.
Has anyone else seen this behavior in Firefox, and is there a fix or workaround?
Your link is just the ID of another element on that same page. I'm assuming Chrome will be a little more smart than firefox and in the bookmarks change that link to https://www.whateverwebsite.com/whatever-page#ovr10 . I'm presuming Firefox only puts #ovr10 in your bookmarks. Only a guess though.
If that indeed is the problem and you want to fix this, changing your link to https://www.whateverwebsite.com/whatever-page#ovr10 would fix that particular issue.
Edit:
Tested on Firefox 65 (stable) and Firefox Dev 69.0b6. Link format does not appear to be the issue. Your code is also bookmarking fine for me.
I have a page that uses unicode control character (\u009d) inside.in windows 8 and google chrome browser there is no problem showing this char but in windows 10 using google chrome this char shows as a rectangle
but using other browsers like firefox or microsoft edge there is no problem at all
This is weird that I have the opposited probelem.
'\u0001' shows nothing in firefox(53.0.2 64 version), edge, ie10.
But on my office pc '\u0001' shows special pic with chrome.
And on my personal pc with different version chrome it shows another pic which is different with the pic as above.
I guess the browser control the vision of the chars. Different browser with version show different results.
When these PDFs are opened in browser in Google Chrome the colours are changed drastically, but when opened in another browser or opened in Preview on Mac the colours go back to normal.
It also doesnt occur in some other languages.
You can see in the screenshot below what it should display (top) and what it is displaying (bottom).
The first page consists of a single large JPEG2000 compressed image: 8 bit indexed color, 1276 x 1790 pixels.
A quick look at a comparison of browsers shows Chrome does not support JPEG2000 (officially at least, since you still got to see something).
There seem to be some plugins that add JPEG2000 support to Chrome, but
that is a local solution, it does not fix the issue for all users; and
Chrome uses its own internal PDF renderer, so it might not work "inside" PDFs.
A Website running on Magnolia 4.4.9 works perfectly good in all Browsers except Chrome. In chrome, one page ends with a ton of cryptic characters. Page
When inspecting the code, I see that they're after the closing </html> statement, even in the original source code (right click -> show page source code). This problem persists on different OS' (Windows 7, Mac OS X, Ubuntu 13.04) and does not always create the same cryptic character sequence.
What could be a possible explanation for this behaviour? Could it be an encoding problem?
http://jira.magnolia-cms.com/browse/MAGNOLIA-3821
Upgrade to 4.4.10 or 4.5.7
HTH,
Jan
When comparing the source in Chrome and Safari on Mountain Lion, I noticed that p#copyright-magnolia has different content between browsers:
on Chrome, I see ... Intuitive CMS Software ...
On Safari, I see ... SEO-friendly CMS ...
Is there any configuration or code that could be causing different content to be sent out to different browsers?
Also, in Chrome, the Elements view of the Developer tools puts the garbage output right after the <!-- end wrapper --> comment and interprets the content, in part, as matched tags. Further, there is a div#a11y-hidden (and other content) right after the garbage and before the closing tags. However, I don't see div#a11y-hidden in the ordinary source view in Chrome or Safari.
Do you see the same thing?
These seem like clues to where the trouble is coming from.