While Mozilla Firefox at last has gained a preference which allows to set Default Zoom level, Thunderbird still haven't got it. This is significant accessibility issue.
There exist a hack which allows to set the desired zoom level using Browser Console in Firefox, it is described here. I supposed that similar approach would work in Thunderbird and found the working command:
ZoomManager.setZoomForBrowser(getBrowser(), 1.2);
If this command is run in Error Console (analog of Browser Console in Firefox and it can be launched by the same shortcut Ctrl+Shift+J), then 120% zoom will be applied to the letter preview pane (at least).
Now the problem is to run this command at Thunderbird start. I installed userChromeJS extension which is developed to support Thunderbird version 91+ and which will "load the contents of chrome/userChrome.js from the user's profile directory every time a window is opened" as is said in its description. Then I added the next code, found here into chrome/userChrome.js:
if (location == "chrome://messenger/content/messenger.xul") {
setTimeout(function() {
ZoomManager.setZoomForBrowser(getBrowser(), 1.2);
}, 0);
}
})();
But it doesn't work, zoom isn't applied to the preview pane as when I run this command manually.
Maybe this code is wrong? I'm not that good in JS to fix it myself.
Related
A fellow developer and I are on exactly the same Firefox version (41.0.1) using the exact same steps to reproduce a text-layout bug on our web application after hard cache refreshes using the same production server (no local assets), and he sees the bug but I don't. We tried on a 3rd developer's browser (same Firefox version) and he does not see the bug, so it seems isolated to this one browser instance. Both machines are identical - Windows 7 on Lenovo Thinkpad T420. It's a CSS text layout bug - text overflows the box onto multiple lines. I've linked to an image below.
Image of bug here
We have also tried:
Running the problem browser in private browsing mode.
Starting the problem browser in safe-mode (to disable plugins).
Doing a diff between the CSS source file each browser is seeing - they are binary equal
Does anyone have any ideas why this might happen or how else to try to debug it?
Edits:
Other things we have tried:
Reset zoom levels on both (ctrl+0)
When debugging JavaScript code using Chrome Developer Tools the debugger pauses on code where breakpoints are not set. I don't have the Pause on exceptions feature enabled, and there definitely are not breakpoints set (see attached image).
I asked a similar question before which was helpful but didn't quite solve this issue (previously I had the Pause on exceptions enabled). In the example below I swapped out the minified version of kendo.all.min.js for the unminified version, which allows me to see where the script execution is being paused, but I don't know why it is being paused. This happens a lot with jquery.min.js too.
I fixed my breakpoints problem by clicking the "Restore defaults and reload" button located in the “Settings” section. To find the button: In Developer Tools click the cogged wheel next to the top right three vertical dots. (Note: If using older versions of Google Chrome, click on the top right three vertical dots and then select “Settings F1”). The button “Restore defaults and reload” is at the bottom right.
Also note that it really restores defaults - you lose all previously saved breakpoints and any files you have open in Developer Tools will be closed.
I got this solution from: Chrome javascript debugger breakpoints don't do anything?
Accepted answer to Import/export Chrome devtools breakpoints & settings between computers reminded me to check "devtools-on-devtools" and in the DevTools' inner Application Local Storage remove the faulty element(s) of the JSON list value for key breakpoints to fix my same issue without resetting everything.
Later it happened again, so I wrote this console snippet:
((stores, matchKey, removeMatchingRegExp, dryRun)=>{for(let store of stores){
let r = JSON.parse(localStorage[store]), l = r.length;
r = r.filter(b=>!b[matchKey].match(removeMatchingRegExp));
if(!dryRun) localStorage[store] = JSON.stringify(r);
console.log(`${dryRun ? 'Would' : 'Did'} remove ${l - r.length} entries from ${store}:`, r)}; return 'OK'})
(['breakpoints', 'domBreakpoints'], 'url',
new RegExp('^https?://example.com/script.js$'), true)
Note:
Provided without warranty: Use at own risk. Backup your data.
Edit it - at least the RegExp argument - to suite your needs.
The last-most boolean should be false to disable dryRun.
Outer DevTools must be reopened for effect.
I was able to resolve this by updating Chrome. I don't think the version matters, just the process of updating resets all of the breakpoints that have been stored in the cache.
F8 has two functionalitys. 1. Skip ot next Breakpoint, 2.stop wherever the Browser is executing code. This works even if you have no breakpoint set. For example spamming F8 when you forgot to deactivate breakpoints might cause the browser to stop anywhere.
When you go to the debugger shortcuts you can see that F8 has the functionality to Pause / Continue. But it sadly seems like you can't split them on two different keybinds.
Since I know this feature I never ran into this "bug" anymore.
I'm posting this answer in case it will help someone who, like me, missed an important clue as to the cause of the phantom breakpoint behavior. In my case, it was "user error" --mine. The root cause was a forgotten "debugger;" statement in a JavaScript file that was itself generated from TypeScript. I had removed the debugger; statement from TypeScript locally, run and tested without issue from localhost. But I had pushed the version with the statement to remote and it built and released to our dev site with the statement present. The dev site build excludes the TypeScript source files. When the debugger statement was hit, Chrome tried to load the .ts source and displayed "Could not load content..." I just assumed it was at a breakpoint (I'd set many during testing). And when I saw "No breakpoint" I assumed Chrome was experiencing the issue addressed in this thread. If I'd bothered to look in the Call Stack trace, I would have seen the source code line in the .ts file and pretty quickly figured it out. Here's a screenshot:
just disable the cache and reload the page, the breakpoints will show up again
I am developing a web-app utilizing Application Cache, and everything is working great on desktop browsers and on Android (even very old & slow android handsets). However downloading the appcache is taking much much much longer on iOS 6 in both Safari and Chrome.
My application cache total size is a mere 2.1Mb, and I have a pretty solid 70Mbps (download) internet connection. I would expect caching to be pretty rapid.
Here are my times so far:
Desktop Chrome: <1s (similar times for Safari & Firefox)
Android 2.3.3 Stock Browser: ~4s (similar times for Chrome & Dolphin)
Android 4.2.2 (Emulated): ~7s (running inside a PhoneGap app)
iPhone 4S 6.0 Safari: 8 minutes!!! (around the same in iOS Chrome too!!)
iPad 2 6.0 Safari: as above!!!
All of these devices are using the same wifi and internet connection, and my iPhone/iPad are otherwise functioning fine (no native apps exhibiting internet speed issues, and regular websites load just fine). There just seems to be something absolutely decimating AppCache download speed under iOS.
The window.applicationCache.status throughout this time is appCache.DOWNLOADING, and I have a progress event running counting the files as they are downloaded, so I'm certain that it is not stuck elsewhere. This just appears to be the time it takes to download. What gives?
Addendum : The iPhone also runs ridiculously hot, and the battery ticks down very quickly during this operation. It seems that something is causing the CPU to run flat-out during this download.
(Note: I can't publish a link to the web-app here as we're still in private beta, but if you would need to see it before you think you'd be able to help diagnose it, email me at the address in my profile and I'll send a link to the app).
Okay, I figured it out with the help of the iOS Emulator, and Xcode Instruments to profile it. (I'm not sure if I should add my solution into the main question, or as an answer, but I thought I'd do it this way as my question is already a little cluttered).
As it turns out, it was actually some erroneous javascript causing the issue, but apparently only on iOS.
The web-app is intended to only be a single page high (no vertical scrolling, except within specific DIVs), so in addition to the usual standard JS code for hiding the address bar...
window.addEventListener("load",function() {
// Set a timeout...
setTimeout(function(){
// Hide the address bar!
window.scrollTo(0, 1);
}, 0);
});
...I had also added in the following:
$(document).scroll(
function(e){
window.scrollTo(0, 1);
});
From looking at the profile results, I was able to see that a lot of time was being spent in scrollTo, so it immediately pointed to this as the cause. Why the scroll event was being triggered so much, I have no idea (this was occurring with no touching of the screen whatsoever).
My initial fix is to throttle that code, but I am now evaluating whether or not I even need it at all. Here is the code I have that fixes it for now (using jquery-debounce, which I was already using for something else):
$(document).scroll(
$.throttle(function(e){
window.scrollTo(0, 1);
})
, 10);
The download time of the application cache is now in line with the Android times. Phew!
The code is getting itself into an infinite loop, as the initial scrollTo function call triggers the scroll event handler, which then repeatedly re-triggers itself! My best guess is that the iOS JavaScript engine handles this infinite loop differently to the other browsers' JavaScript engines.
I use Chrome Developer Tools to debug my JavaScript code, but I have one pet peeve with the way Chrome lets you edit the JavaScript files under the Scripts tab. Sometimes, I do not realize that I am in Chrome and I start making changes to the code under the Scripts tab, only to realize when I refresh that the changes I had just made were never saved to disk!
I was wondering if there is way to make the code shown in the Scripts tab read-only, so that if I try to edit the file in Chrome, I'll see that it's not editable and then realize that I'm not in my IDE.
Use the following process to make the script source read-only in Chrome 32+:
Go to the chrome://flags/#enable-devtools-experiments URL
Select Allow UI Themes
Open Chrome Dev Tools
Select Settings (Press F1 or click on the three dots on the far right)
Select Allow UI Themes
Create a DevTools theme with the following style:
.content-view.script > .text-editor { -webkit-user-modify: read-only !important; }
Publish it the the Chrome Web Store
Install the Theme
Restart Chrome
References
Custom.css has stopped working in 32.0.1700.76 m Google Chrome update
Sample DevTools Theme Extension
Chrome Developer Edition Dark Theme for Chrome Dev Tools
WebCore Inspector Script Content View
Chromium User Data Directory
Use the old process for Chrome 31-:
Use a user stylesheet to disable the script tab altogether:
.toolbar-item.scripts { display:none !important; } /* Hide Scripts Tab */
Or simply make the script source read-only:
.text-editor-editable { -webkit-user-modify: read-only !important; } /* Old selector */
.content-view.script > .text-editor { -webkit-user-modify: read-only !important; } /* Older selector */
.editing { -webkit-user-modify: read-only !important; } /* Generic Selector */
Here are several possible locations of the file:
Windows 7 Chromium:
%LOCALAPPDATA%\Chromium\User Data\Profile 1\User StyleSheets\Custom.css
Windows 7 Chrome:
%LOCALAPPDATA%\Google\Chrome\User Data\Default\User StyleSheets\Custom.css
OSX Chrome:
/Users/YourUsername/Library/Application Support/Google/Chrome/Default/User StyleSheets/Custom.css
Ubuntu Chrome:
~/.config/chromium/Default/User\ StyleSheets/Custom.css
Use the following Chrome Devtools URL to reference the relevant styles:
chrome-devtools://devtools/devTools.css
As far as I know, there is no option to disable script editing in the Chrome/WebKit Developer Tools.
Below are two three possible solutions:
Solution 1:
Make an extension that shows an alert every time you make an edit:
JavaScript:
chrome.devtools.inspectedWindow.onResourceContentCommitted.addListener(function(resource, content) {
alert("WARNING: Your changes will not be saved!!");
// Optional, but and extra layer of "protection", if you don't want/need it just remove the "experimental" permission from the manifest
if (chrome.experimental) {
chrome.experimental.devtools.console.addMessage("error", "WARNING: Your changes will not be saved!!");
// Shows in red
}
});
Extension (unpacked, first enable the experimental extension API's under chrome://flags): http://www.mediafire.com/?wb1r67ron0x6szh
Solution 2:
Modify the source and run a custom build:
The other option would be to modify the developer tools source, please see https://developers.google.com/chrome-developer-tools/docs/contributing for more details. If you did that, all you need to do is remove the text-editor-editable class from the editor container (line 1279, DefaultTextEditor.js).
Solution 3:
Make chrome auto-save your files:
The third option would be to enable chrome to save your files, there are a number of extensions that do this namely Tincr. Tincr also let's you live-reload your files and offers complete syntax highlighting.
My personal opinion is that this is the best solution.
I'm working on a file upload utility based on Valum's Ajax-Uploader. The idea is similar to the Gmail attachment process. The user should be able to drag a file from the desktop into the browser window and onto the file upload area to get it to upload. This works fine in the browsers that support this functionality (Firefox 3.6+, Chrome 7+).
The problem I'm running into are the styles that should be re-drawn when the user:
Drags the file anywhere in the browser
Drags the file into the upload area
I have tested in the exact same browser versions on WinXP, Vista, and Win7. The appropriate styles are redrawn. However, in Windows Server 2003, they do not.
In Win2003, when I inspect the div that should be redrawn via Firebug, the "drop-area" and "drop-area-active" classes are applied correctly. Firebug even shows the correct style declarations, but the changes are never visible.
The only difference between FF and Chrome that I'm able to spot is that in Chrome, the "drop-area-active" style is displayed for a split second when the user drops the file.
I'm not positive that it is a Windows2003 issue, but that's the only OS in which I'm able to recreate the bug.
Edit:
If you're running Win2k3, try the Gmail drag'n'drop functionality. I can see the alternate styles in other OS's, but not Win2k3.
Edit #2:
Still seeing this issue in many different places. Anyone have any suggestions? I have submitted this as a bug to the Chromium Project. Issue 68632.
http://code.google.com/p/chromium/issues/detail?id=68632