Firefox 31 Web Console Layout - firefox

Firefox 31 has changed my web console layout and I can't find the option to change it back. Being that I have a widescreen monitor I prefer the console to the right. When I select an array/object to view it opens it in a split as expected, but ever since the update I can't get the split to stack them vertically so they can use more width. Am I just not seeing this option?
Update: For Firefox up to v33 use this plugin, for 34+ behavior has changed. Read this thread on Bugzilla for details: https://bugzilla.mozilla.org/show_bug.cgi?id=1084004

This was added in Firefox 34, now in Beta. It is not in Firefox 33, the current release.
If you have the toolbox docked to the side, the Object Viewer pane will automatically drop to the bottom if the toolbox gets too narrow, see this gif for a visual example:

No, you are not missing the option. The option does not exist.
However, here is a quick-and-dirty extension that does what you want for Firefox 31.0 through 34.0:
http://www.mediafire.com/download/oxt4c5o5vypca85/place-webconsole-object-view-vertical%40makyen.foo.xpi
I tested it on Firefox 31.0, 32.0.1, 32.0.2, 33.0b4 (current beta), and 34.0a2 (Aurora, the current alpha). All of them worked. The file the extension changes, webconsole.xul, has 4 slightly different versions in that range of Firefox releases. One of the changes was between 32.0.1 and 32.0.2.
I had another extension for which I was already working on a similar set of compatibility and testing and then Mozilla released FF 32.0.2 today. Leaving this solution as only compatible for 31.0-32.0.1 just didn't sit well with me, so I did the mods to give it the wider compatibility range.
In 34.0a2 the stock behavior of this part of the webconsole is a bit different. The object view automatically shifts from vertical to horizontal depending on how wide the devtools sidebar is. Visually, this is similar to how the inspector behaves in 31.0 (and later). The above extension, when installed on 34.0b, will lock it in the vertical position. Personally, I really don't like the auto-choosing of vertical/horizontal. I would want a control and be able to lock it the way I want it when I am viewing it. This is not supposed to be a glitzy wiz-bang UI thing to get the masses interested. This is a: I want to get my work done now and I want it my way because that's how I work fastest/best. Sorry, I got up on my soapbox there a bit.

It's the icon that has a rectangle at the bottom. In your case (Where the yellow arrow points):

Related

Scene Builder preview shows all objects much larger than end result

Here we have a preview of a window in Scene Builder behind the actual result when run with Netbeans. You can also see that my minimum sizes are set to USE_PREF_SIZE, with the values being auto-filled when I adjust the size of the window. The size difference between the windows is the first obvious difference.
Further, you'll notice that everything inside the window is smaller as well, all buttons, tables, fonts, etc.
I'm using Netbeans 8.2, Scene Builder 11.0.0, and JDK 8 update 251. Any ideas?
Figured it out! Hopefully this will be of some use to another aggravated user somewhere in the world.
The issue for me is that Windows was automatically scaling NetBeans. I found this resource for how to stop it:
Windows 10 does this for you now. Right click on your Netbeans shortcut (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\NetBeans) and select Properties. Go to the Compatibility tab and then select Change High DPI Settings. From there, check the Override High DPI Scaling box and set it to System.

"Auto Layout before OS X 10.7"

I have an app in the app store, FractalWorks, which is based on a very old code-base. It's a big app, with quite a few screens. It was created in Objective-C before auto-synthesized properties were a thing, to give you an idea of how long ago it was created.
I wrote the app when I had a full-time gig as an independent software developer. I've since taken a day job, and support my apps in my spare time.
It still sells fairly well, and I recently used to add a section to the Wikipedia article on the Mandelbrot set on 3D images: https://en.wikipedia.org/wiki/Mandelbrot_set#3D_images_of_Mandelbrot_and_Julia_sets
I'm fluent in Auto-Layout now, but haven't taken the time to update the app's XIB files from "struts and springs" style to Auto-Layout - nor do I want to invest the time to do so if I can possibly help it.
I want to add a minor enhancement to the app that involves adding some UI elements and making one of the windows slightly taller. The minute I try to use Interface Builder to edit my XIB, it apparently silently changes it to Auto-Layout, and then complains about "Auto Layout before OS X 10.7". (It was released to the app store for OS X version 10.4, if memory serves, and I've moved the OS version up to the lowest version I could get away with in order to support legacy customers. It currently supports ≥10.6. The original, pre app-store version used even older OS versions.)
Googling this error suggests I use the file inspector on my XIB file to un-check a "Use AutoLayout" checkbox, but I don't see any such checkbox.
What am I missing?
If I use Xcode's code review button to compare the XIB file before and after editing it, various "tool version" values are changed, as well as it gaining a setting useAutolayout="YES". Editing that to read useAutolayout="NO" does not solve the problem.
All the credit goes to matt and his comment.
1. In the Navigator (left panel) go to issue navigator and click on the error.
2. In the Inspectors panel (right panel) the Size inspector will be automatically selected. Switch Layout from Automatic to Translates Mask Into Constraints.
Update: It's called Autoresizing Mask now.
3. Repeat for every occurrence of this error.
You may end up with an error not in the Illegal Configuration group like the following which opens the All Messages view in the middle and doesn't open the Size inspector.
This is a compile time error, just build/run your app again.
And also from the previously mentioned comment:
Be careful not to make any constraints, as that will cause an incoherent situation.
If you have multiple auto layout errors, which in all likelihood you will have, select all the controls in a window and perform the operation once rather than for each individual control. Repeat for each window.

Is Pinch Zoom(zooming like we do on image) available in Firefox Developer Edition for macOS? If yes, how to enable it?

I have tried the solution given on this link
https://itstillworks.com/enable-zoom-pinch-firefox-macbook-21731.html
This seems to just increase the zoom percentage as can be done by Cmd + +. But what I wanted was the way Chrome and Safari do it, to zoom into a particular part of the page(the part where the pointer is) and then you can scroll also in those particular settings. Like zooming in as if the webpage was an image.
Is this feature available in Firefox?
Open a new tab in Firefox and type in about:config to go to its configuration window. This will probably take you to a window that warns you about the risks of incorrectly modifying settings. Simply click "I accept the risk!" to continue. Then search for the setting called apz.allow_zooming and set it equal to true.
Pinch zooming is used by default starting in Firefox 83, released on November 17, 2020, both on Windows and Mac. (release notes) As before, whether pinch zooming is enabled is controlled by the apz.allow_zooming setting in about:config, so you can disable it if you like.

Scrollwheel not working in Chrome for OSX

I have an application built with JSF and PrimeFaces. I am using a layoutPane and within it are two panels. I have set up CSS to scroll the content sections of the panels however the scrollwheel will not work on OSX using Chrome version 51. I can however use the arrow keys to scroll the section. The scrolling works as expected when using Safari and Firefox but not Chrome.
I should note also that I am using a Mac Pro with Retina display. I also have a second monitor attached that is a HP w2207. To make things even more interesting, if I drag the Chrome window to the HP monitor the scrolling works as expected. Dragging the window back to the laptop Retina display and the scrolling no longer works.
I have tried various system settings and nothing has worked. I have also tried altering the HTML/CSS thinking maybe there is some kind of collision between the parent panel and the child panels but I have not been able to come up with a fix.
Has anyone experienced this issue before or could point me in the right direction?
Upgrade Chrome to version 52.
I'm working on a different stack, but the issue seems to be exactly the same: in some cases scroll doesn't work and it happens only when I'm using Chrome 51 and Retina. I wasn't able to find the cause, and the only solution that I know is upgrading Chrome.

Xcode Developer Documentation Link Hover Jumps To Top

I don't know how I got into this state, but the Xcode documentation window has been exhibiting this strange behavior of "jumping to top" whenever I hover over a link in one of the doc files.
For example, I'll be scrolling down to, say, the methods of a Class Reference, and as soon as I hover over one of them, the doc window jumps right back to the top.
Has anyone else encountered this? If so, is there a fix for within Xcode?
Meanwhile, opening up the doc in a browser works around the problem.
Thanks for the replies everyone!
Meanwhile, I have just stumbled upon a workaround.
To preface, I have to clarify/correct two things for my particular case:
The problem only occurs when hovering over the links in the Tasks section.
The jump doesn't necessarily go to the top-of-page. Rather, it goes to wherever the original landing spot was when you opened the doc. (In URL parlance this is the fragment, e.g. #//apple_ref...).
On to the workaround:
In the Xcode doc viewer (and even in Safari), there should be a "Jump To..." drop-down in the "developer-documentation" window located to the right (and as a peer) of the "table of contents" expander when this problem occurs. You only need click on it once, dismiss it, and then the jumping problem goes away!
I've encountered it (only when viewing the docs in Safari, not the doc viewer itself), and I believe it's a known bug fixed in Xcode 3.2 (for Snow Leopard).

Resources