adobe/brackets-app

Deprecated CEF1-based app shell for Brackets. Use https://github.com/adobe/brackets-shell instead.

Don't use this repo!

This project is not maintained and is archived.

As of Sprint 13, Brackets has a new CEF3-based application shell. Please use the new shell for all development.

For general information on Brackets, see the brackets repo or brackets.io.

Please don't file bugs in this repo--instead, file them in the brackets repo: https://github.com/adobe/brackets/issues

brackets-app's Issues

Brackets doesn't remember current file if not in the working set

1. View a file in the file list (not ws)
2. click F5 on Win or CMD+R on Mac (or quit & reopen Brackets)

Result: After the refresh first file in working set is shown or none if none in the ws. User need to remember fil he was viewing and manually go back to the file.

window.prompt() doesn't work

Steps:

1. Open the developer tools console
2. Type window.prompt("Foo")

Result:
No UI shown. Console prints null.

Expected:
A native popup containing a text input appears. When dialog is Ok'ed, console prints whatever was typed in the dialog's input.

It's a little surprising that alert() works but this doesn't. It works fine in normal Chrome.

We don't have any direct need for this, but it's something we -- and plugin authors -- might want to do when mocking up something quickly. It will be surprising to devs that this doesn't work.

CEF doesn't handle focus/blur correctly

This bug tracks the "todo" to remove a work around for a CEF bug when a fix becomes available

CEF doesn't handle focus/blur correctly. See CEF bug #501 for details:
http://code.google.com/p/chromiumembedded/issues/detail?id=501

"Brackets" title/link in upper left is rendered in hover state when window first opens

1. Launch Brackets, but keep your mouse away from where the window will eventually appear (e.g. keep mouse on taskbar/dock)
2. Observe the "Brackets" label in the upper-left of the UI (white on black text)
3. Move the mouse onto the Brackets window

Result:
In step 2, the label's background is lighter -- it's in its rollover state. In step 3, the label un-highlights... until you mouse over it for real, of course.

It's as if the window is getting a spurious mousemove(0,0) event when initialized... or something of that sort.

Expected:
Nothing shows its rollover state unless you actually move the mouse over it.

Implement fs.unlink()

NativeFileSystem API tests use fs.writeFile() to create a new file. Currently, there is no way to remove files via the JS-Native bridge.

Brackets won't launch on Windows XP

If you run the latest brackets.exe on a Windows XP box, you'll get an error dialog about being unable to find the API SHGetKnownFolderPath, which only exists in >= Vista. Brackets does not launch after that.

According to the docs (http://msdn.microsoft.com/en-us/library/windows/desktop/bb762188%28v=vs.85%29.aspx), there's a similar older method called SHGetFolderPath that is hopefully easy for us to use instead.

Workaround: sync brackets-app backward to about 95a470 or so.

FileWriter.write() cannot write to a file that doesn't already exist

This repros on both Mac and Win.

1. Open a file in Brackets and make some changes
2. Go onto disk and delete the file
3. Go back to Brackets and Save

Result:
Error popup saying "The file could not be found."

Expected:
A new file is created where the old one used to exist.

We could work around this by calling FileEntry.getFile() with create: true (the way File > New works), but I believe by producing this error we are not matching the HTML spec for FileWriter.write(). The spec states that an error is produced if (a) the parent directory does not exist, or (b) the file does not exist and offset has been set to something != 0. Neither of those is the case here, so the call should succeed.

Marking as medium priority for Sprint 3 because this somewhat damages the story about checking for external changes: if the file has been deleted externally, you can't simply save to recreate it. (You can still use copy-paste to avoid losing work, however).

Hard crash if "Refresh" is initiated after closing main window

Steps:

1. Launch Brackets
2. Close the Brackets window (via the "X", not by quitting the app)
3. View > Refresh

Result:
Beachball for a moment, then crash

Expected:
a) Menu item is disabled
or
b) Closing the main window automatically quits the app, so step 3 is impossible
or
c) Choosing 'Refresh' when main window is closed brings up a new main window

This is similar to issue #25. My vote would be to have closing the main window automatically quit the app.

All windows frozen if you pause on a breakpoint in one window

1. Debug > New Window to open a second Brackets window
2. Open the Developer Tools on the second window
3. Set a breakpoint somewhere obvious (e.g. the File > Open handler)
4. Do stuff to hit the breakpoint in the second Brackets window
5. Return to the original Brackets window and try to do anything

Result: both Brackets windows are frozen

Expected: only the window that is the target of Developer Tools should be suspended
(note that the breakpoint itself is specific to the second window, so I'd expect the results of hitting it to also be scoped to that one window)

This makes dogfooding a challenge because you can't use your "master" Brackets to e.g. read through the source code while the "guinea pig" copy of Brackets is paused on a breakpoint.

It will be a blocker for normal users once we do the story to preview within Brackets (as opposed to launching Chrome), since hitting a breakpoint in the user's website would also freeze Brackets.

Line numbers in Developer Tools window sometimes stop scrolling (and desync from code) when paused at breakpoint

Steps:

1. Launch Brackets
2. View > Developer Tools
3. In Scripts view, open ProjectManager.js
4. Put a breakpoint in loadProject()
5. Go back to the Brackets main window and Refresh
6. Look at the Developer Tools window again

Result:
Line numbers are wrong: when you scroll the code view, the line numbers do not scroll. Since they're initially out of sync too, the breakpoint marker appears to have disappeared.

Expected:
Line numbers scroll width editor, as they would when you're not paused -- or when you hit the same breakpoint a 2nd time.
(Bug seems to only happen if the first time a given JS file's source is shown after Refresh is when you hit a breakpoint in that file).

ShowOpenDialog on windows needs to use passed in file types and multiple selection

See brackets_extensions.cpp::ExecuteShowOpenDialog

Note: would also be good to support all file types

White line separates menu bar from UI

1. Look at the project panel on Windows (maybe only XP??)

Result: a 1px white line is visible between the dark project panel background and the gray native menubar background.

Expected: no such gap -- project panel immediately abuts the gray menubar background. Northstar mockups show no gap between native chrome and project panel bg.

I'm pretty sure the white line is not part of the HTML content. It may be a part of the native menu bar itself, or it may be a gap in the layout between the menu bar and CEF control...

After hitting breakpoint on refresh, line numbers in dev tools window don't scroll

1. From the Project panel, open the brackets folder if it's not already the current project
2. View > Show Developer Tools
3. Set a breakpoint in a function that gets called on startup, like ProjectManager.loadProject()
4. View > Refresh
   -> The app restarts and hits the breakpoint
5. Scroll around in the code in the Developer Tools window

Result: The line numbers don't scroll with the code (which is why you also don't see the breakpoint marker at the line you stopped at). This doesn't seem to happen every time you hit a breakpoint, but it does seem to happen whenever you hit a breakpoint after refreshing the app, and I've seen it happen in some other cases as well.

Cannot launch if Brackets is in a folder named other than "brackets-app" or if that string occurs > once in path

Steps A:

1. Copy your Brackets source tree into a root folder named something other than brackets-app
2. Launch Brackets

Result: crash (looks like an NPE)

Steps B:

1. Copy your root brackets-app folder into a path that itself contains the string "brackets-app"
   (e.g. c:\brackets-app-sprint3\brackets-app...)
2. Launch Brackets

Result: fails to load index.html -- looking in the wrong folder (e.g. c:\brackets-app... in the above example)

This latter case can easily occur if you grab a copy of Brackets via the "Downloads" tab on GitHub: it gives you a ZIP file where the folder structure is ...\adobe-brackets-app-sprint-2-28-\adobe-brackets-app-\brackets-app...

Rollovers adjacent to window edge get stuck when you mouseout of window

Steps:

1. Move mouse over the Run Tests button (or anything else clickable in the black top bar in our UI)
2. Move mouse vertically up out of top of window

Result:

• Run Tests button remains highlighted
• Mouse is stuck as "pointing finger" (link) cursor

Expected:
Run Tests button un-highlights and mouse reverts to normal pointer arrow, just as if you'd moused away from the rollover in any other direction.

We attempt to open binary files on Windows

Steps:

1. Try to open styles/images/.png in our source tree

Result:
Binary gibberish shown in editor.

Expected:
What happens on Mac -- Error dialog pops up, and we do not open the file (goes back to the previous editor).

Crash when hitting breakpoint in Brackets code

I've run into a couple of cases now where hitting a breakpoint in Brackets code in the developer tools causes a hard crash. It doesn't happen with every breakpoint, but with certain breakpoints it happens all the time. The same breakpoint doesn't crash in the previous version of CEF.

We'll need to narrow this down to a small test case that we can file against CEF.

CodeMirror keymap isn't working inside brackets-app

1. Open brackets-app
2. In the empty editor, type some text
3. Hit Cmd-A to select all

Result: Doesn't work. Some other keyboard shortcuts, like Cmd-Z, appear to work, but they're actually going through the browser, not CodeMirror, and so don't actually do the right thing. This blocks implementation of things like figuring out whether files are dirty and need to be saved.

Opening Brackets on a small monitor makes menubar disappear

If you open Brackets on a laptop screen instead of a big external monitor, the top menu doesn't show. This appears to be a problem with the standalone app only, as it works fine in a small browser window.

Hard crash trying to open files in rapid succession

Steps:

1. Press Ctrl+O to bring up the Open File dialog
2. Double-click a file in the list to open it
3. Repeat 1-2 a few times

Result:
Brackets terminates suddenly one of the times you hit Ctrl+O. I seem to get it in < 5 tries every time.

I tried to repro this on Mac but no luck*, so I'm assuming it's Windows-only.

(* for a slightly twisted definition of "luck")

Developer Tools window is larger on Windows

Steps:

1. View > Show Developer Tools

Result:
Developer Tools window is just as big as the main window.

Expected:
On Mac it is quite a bit smaller.

Ideally, on both platforms it would remember the window's last size/position from your previous launch. Then the default window size wouldn't matter very much :-)

Command line arg for URL

brackets-app should provide a command line arg to specify an arbitrary URL for the embedded browser. To automate unit tests and run them in the app shell, the unit test scripts would launch brackets-app using this command line arg with the proper test runner HTML (QUnit) or browser capture URL (JsTestDriver).

Lion: brackets.app does not run if built in debug mode

When brackets.app is build in debug mode on Lion, an 'assert' continually fails in a message loop. This assert failure pauses the debugger, making the app effectively unusable (and un-debuggable).

Specifically, this is the assert that fails:

ASSERTION FAILED: !view() || !view()->layoutStateEnabled()
/Users/marshall/code/chromium_release/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../rendering/RenderBox.cpp(1391) : virtual void 

Some sleuthing by our talented intern Jonathan found that this is caused by a bug in WebKit. Here's a patch that fixes it:
https://bug-73348-attachments.webkit.org/attachment.cgi?id=118296

This patch has already been incorporated into the latest Chromium code, but is not yet in the Chromium version that CEF uses (even latest CEF source).

Our options are:

1. Compile CEF from source, adding in this patch
2. Wait until this trickles down into CEF
3. Revert back to an earlier build of CEF

Fix chmod calls on Windows so unit tests pass

See todo brackets_extensions::ExecuteSetPosixPermissions

Saving a file in Brackets corrupts the file.

1. Open a file and make some changes.
2. Save the file.

Result: File content is written out with extra blank characters.

Unnecessary scroll bars show up in working set after closing an updated file w/o saving it.

1. Open two files in working set and select the first one. (the one on the very first line in the working set)
2. Make some changes and then press Ctrl/Cmd+W to close it.
3. Click "Don't Save" when prompted.

Result: A horizontal scroll bar appears in the working set and then the triangle is now pointing to the wrong location.

Cmd+R crashes brackets app on Mac and Windows

1. Open Developer Tools.
2. Set focus back into the main editor.
3. Press Cmd+R to reload project.

Result: On mac you get a crash report.

File is not restored when not in working set (Win / Mac )

F5 / CMD+R is not restoring the file if not in the working set.

WriteFile on windows need to handle encoding types and use a temp file

see todo in brackets_extensions.cpp::ExecuteWriteFile

Minor: View > Refresh vs. Reload inconsistency

On Mac, the menu item is View > Refresh.
On Win, the menu item is View > Reload.

We should be consistent :-)

Windows: View > Reload native menu closes Brackets window, whereas F5 and HTML menu work fine

Quit only happens via the menu, refresh works fine using F5, but Ctrl+r seems not to show effect.

File names with certain characters (e.g. \r) cause readdir() to crash

Steps to repro:

1. Open your /Applications folder in Brackets
2. Expand the folder for any Adobe CS application (e.g. Flash Builder 4, Illustrator CS5, etc.)

Results:
Folder does not expand. "Unexpected token" error is logged to JS console.

Expected:
Folder expands correctly, no error logged.

So here's what's going on: many applications' root folders contain a special file called "Icon\r" (where \r is an actual newline char). When readdir() calls the native method ReadDir() (ExecuteReadDir() in the ObjC source), it gets back JSON with a \r character inside a string literal, which is illegal syntax in JS, and thus its JSON.parse() call fails.

I think the root bug is actually in NSArrayToJSONString(), which should be escaping special characters in strings before spitting them out into the JSON source. We should probably put that functionality in a new utility function so that we can leverage it in other to-JSON conversions.

Win: no application icon in taskbar, alt+tab list, file explorer, etc.

We need to create an icon resource in several resolutions and wire it up to the .exe and main window...

Unit tests for LowLevelFileIO should assume asynchronicity

Currently, the unit tests for LowLevelFileIO are only correct in the case where the underlying API is implemented synchronously. Since they're actually testing an API that is supposed to be asynchronous (and that we expect will eventually become asynchronous), we should make the tests work as if they assumed the implementation was async, so that when we do eventually implement async we can use them to verify that everything's still working okay.

Error when launching if installed in a path that contains a space

Occurs on both Mac and Windows

1. Download the Sprint 5 build from the Brackets wiki
2. Extract the zip file into a folder that contains a space such as "brackets app"
3. Launch the app

Result: An error dialog pops up. If you dismiss it, another error dialog pops up. You can quit the app but it can't be run.

Workaround: Rename the containing folder to remove the space. Delete the cefCache folder. It should now work.

ShowOpenDialog on Windows should use IFileDialog instead of SHGetPathFromIDList

See todo in brackets_extensions.cpp::ExecuteShowOpenDialog.

Making this change will make the open dialog use the new Win XP and later file dialog that includes search, favorites, and other browsing shortcuts.

Example usage for IFileDialog is here:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb776913%28v=vs.85%29.aspx

Load Project is slow when a file is in the working set

1.) use a simple project with just one HTML file.
2.) if the file is just open but not in the Working set it took around 90ms to reload the project (debug Show Pref data)
3.) Do the same with the file being in the WS

Result: Load project takes 3 to 4 times longer although the open file (parsing?) is counted separately.

Not sure if Brackets or Brackets App???

Native dialogs are not modal on Win

Steps:

1. File > Open or click the Open project button
2. Click anywhere in the main Brackets window

Result:
Brackets window comes to the front, and is fully interactive: you can edit files, etc.
(The dialog remains open in a separate window, which you can get back to via Alt+Tab or the Taskbar).

Expected:
Interaction with Brackets window is blocked. Dialog stays on top.
Ideally, the dialog should not get its own Taskbar entry -- that is highly unusual for modal dialogs on Win. (Hopefully making it modal will fix this for free).

Hard crash if Show Developer Tools after closing main window

Steps:

1. Launch Brackets
2. Close the Brackets window (via the "X", not by quitting the app)
3. View > Show Developer Tools

Result:
Beachball for a moment, then crash

Expected:
a) Menu item is disabled
or
b) Closing the main window automatically quits the app, so step 3 is impossible

Brackets frequently crashes while running unit tests

Brackets.exe crashes every few times I run unit tests on Windows. It seems to crash more often if I have Developer Tools open for the Jasmine runner window, but it crashes sometimes even without that.

It sounds like this may be Windows-specific since the Mac-using people on the team have never seen this. (Or it could be my-computer-specific... remains to be seen).

Next time this happens I'll break into Visual Studio and see if I can get symbols attached again...

Properly find index.html file of Brackets when loading native win shell

see todo cefclient_win.cpp

Mac only: When Brackets is minimized ALT+CMD+I doesn't bring up the Dev Tools

I verified that other Apps like Outlook or Finder invoke other process windows in that case. The expected behavior is similar to the maximized state.

Brackets hangs onto file handle forever after fs.readdir()

Steps:

1. Expand some subfolders within the project Brackets has open
2. Try to delete one of the folders on disk
3. Open a tool like Process Explorer and view the file handles that Brackets.exe has open

Result:
Step 2: cannot delete folder: it is in use by another program.
Step 3: Brackets has >= 1 handle for every directory that has been expanded in the project tree. The handles sit there forever (they seem to persist even across refreshes -- only quitting the whole app cleans them up).

Expected:
Step 2: no problem deleting it
Step 3: no file handles open unless Brackets is actively doing disk activity

Marking this high priority since it presumably breaks Git updates sometimes, thus blocking dogfooding on Win. I'm not 100% convinced this is such a huge issue that it's required for this sprint, though...

Open project folder picker dialog doesn't remember last location

1. Click the project tree Open button
2. Browse to a folder and select it
3. Click the Open button again

Result:
The folder picker dialog starts out back at the top level (your desktop)

Expected:
Remember last location: folder picker dialog starts out at the last location it was Ok'ed on. (Or maybe starts out at the root folder of the current project -- that way we also cover the case where Brackets was just launched but we reopened the previous launch's project).

On Mac, I believe it already remembers the last location.

Blinking cursor is still visible when Brackets window not active / focused

Steps:

1. Open any file, so that you get a blinking cursor in the editor
   2a. View > Show Developer Tools

• or -
  2b. Switch to a different app where Brackets is still visible behind it

Result:
Blinking cursor is still visible in the code editor

Expected:
Cursor is hidden, just as in any other text editor that doesn't have focus

The cursor does hide if the editor loses focus within its own window (e.g. by clicking in the 'toolbar' that shows the filename). And vanilla CodeMirror works as expected with both varieties of focus loss (within window and via window deactivate).

This suggests the problem is with the native shell -- the browser seems unaware that its host window became deactivated, and thus won't fire the JS deactivate event that our/CodeMirror's code is listening for.

Right-click shows useless context menu with Back/Forward options

Steps:

1. Right-click somewhere in the Brackets UI outside of the editor pane

Result:
Mac -- a context menu pops up with two items, both disabled: Back, Forward
Win -- a context menu pops up with four items: Back, Forward, Print, View Source. Back/Forward seem to do nothing other than toggle each other's enablement. Print opens a native print dialog, and View Source opens a generated copy of brackets.html in Notepad.

In all cases, the context menu items are essentially useless.

Expected:
No menu appears. As in a native app, right-clicking in areas with no useful context menu functionality should do nothing.

View > Show Developer Tools should bring it to front if already open

Steps:

1. View > Show Developer Tools
2. Switch back to main Brackets window. Resize it so it totally covers the Developer Tools window.... do a bunch of work and gradually forget that you have Developer Tools open.
3. View > Show Developer Tools

Results:
Nothing appears to happen. Click it again, get frustrated... eventually realize the window is already open, just hidden behind the main window.

Expected:
Should bring Developer Tools window to the front if it's already open.
(Although maybe if it's already open and focused, then this menu item should close it instead?)

Brackets hangs onto file handle of last folder File > Open was Ok'ed in

Steps:

1. File > Open
2. Browse to some file and open it (this bug is most clearly problematic if you open a file outside your project)
3. (optional) Close the file (makes the incorrectness of the behavior more obvious)
4. On disk, try to rename or delete the folder that contains the file from step 2 (or any ancestor of that folder)

Result:
Windows won't let you: says folder is in use by another program.

Expected:
Brackets should not keep any folders locked -- especially a folder the user is not even dealing with anymore.

Workaround:
A) Quit & re-launch Brackets, or...
B) File > Open a file from some different folder, unlocking the original folder and locking the new one

Ctrl+R or F5 in Developer Tools window just quit Brackets.

1. Open Developer Tools wiindow.
2. Press F5 or Ctrl+R.

Result: Brackets just quits.

Mac: user should be able to re-open editor window if it is closed

Mac only

Right now, if the user closes the main window, he's left in a strange state. The app is still running, but there's no way to get a new editor window.

I think one of the following should happen:

1. Clicking dock icon or choosing File > New Window should bring up a new editor window (more mac-y)
2. Closing the window should exit the app (less mac-y)