adobe / brackets Goto Github PK
View Code? Open in Web Editor NEWAn open source code editor for the web, written in JavaScript, HTML and CSS.
Home Page: http://brackets.io
License: MIT License
An open source code editor for the web, written in JavaScript, HTML and CSS.
Home Page: http://brackets.io
License: MIT License
Opening a project with a long file name causes the "Open" button to wrap to next line, which is half off the header bar.
Steps:
Result:
data.inst.data.core.to_open
to [undefined]
Workaround: Delete your cache at /Users//Library/Application Support/com.adobe.Brackets.cefCache. This only has to be done once. Following unit test runs will complete without issue.
Result
"Error opening file" error is displayed
Expected
Folder opened/closed state should be toggled (same as clicking arrow).
Currently, there is some code (initProject()) related to the initialization of the project UI in brackets.js (it attaches various event handlers to items inside the project panel). In general, it seems like any initialization of UI that's associated with a module should be moved into that module.
A bigger issue is that ProjectManager really includes both model and view code, whereas our other Managers are really models, I think. It might make sense to factor the UI code out into a separate ProjectView, and have the ProjectManager dispatch events to the view. (Or perhaps we should just rename ProjectManager to ProjectView.)
Currently, when you run Brackets in the browser, we add dummy content to the tree, but don't have any content in the browser. We should add dummy content there as well, so we can test editor functionality in the context of the browser.
All public constructors should verify that they were called with 'new'. If they were not, they should throw an Error.
It should look something like this:
function Waffle(diameter) {
if (!(this instanceof Waffle)) { // ERROR: constructor called without 'new'
var e = new Error("Waffle constructor must be called with 'new'");
e.detail = { waffleSizeDesired: diameter };
throw e;
}
this.diameter = diameter;
this.tastes = "yummy";
}
In our unit tests for FileCommandHandlers, there is a beforeEach() function that purports to reload the window in between tests, ensuring a blank slate for each test. Although it does so, it always hangs onto the JS module objects from the initial window load, meaning that all tests share the same module state -- not a blank slate at all.
It turns out this is quite tricky to fix, because it's difficult in JS to wait for a window to reload. The old document does away asynchronously, so it's hard to know when to attach load/ready listeners. If you attach them too soon, you'll attach them to the old document -- meaning, depending on which call you're using to attach them, they will either run immediately (too early) or will never run (since the old document goes away).
This isn't a problem on master because the file commands are essentially stateless. However, the working set stuff makes them not stateless, so that having all these supposedly independent tests sharing state becomes a problem.
Jason and I are looking into this.
Results:
folder is selected
Expected:
folder is not selected
Results:
folder is still selected
E-mail thread comments:
[ty] Bug, looks like the default jstree implementation is to select the parent
[peter] I’m not sure what the expected result should be here. In Windows, when you collapse a subtree containing the selection, this is what happens. On Mac, the rule seems to be that we clear the selection instead. In Espresso, this actually clears the editor too (i.e. it closes the open doc from the hidden subtree and doesn’t open any other doc).
[randy] It doesn't make sense to me to clear the editor. I'd rather see the current working set file displayed until something meaningful is selected in the project folder. I suggested to not select the folder for the sake of consistency.
Result: Looks a little odd when it's clipped, because there's no visible affordance underneath the "Project Files" header that's clipping it. One solution I saw recently that I liked is in Gmail: when you scroll the content, a shadow appears underneath the header area. Seems simple to implement.
Steps:
Result:
Both times you open the dialog, you start in the root folder of the project.
Expected:
The second time, you should start in whatever folder you selected from within the first time (e.g. your desktop).
Steps:
Result:
The new item in the folder tree disappears. No file is created or opened in the editor, but no error message is shown either.
Expected:
Error dialog appears.
Ever since our LESS refactoring, the text cursor in the code editor has been a solid blue box the full width of one char. Previously, it was a thin vertical line at the left edge of the char's bounds.
Normally, a full-width box is only shown in an editor when in 'overwrite' mode, and the thin I-beam cursor is shown most of the time (i.e. when in 'insert' mode). We should follow this convention too.
We probably shouldn't do a ton of visual tweaking until we have actual visual designs, but if it's easy, we should reduce the padding between the items in the file list--the spacing feels a little loose. Might also want to consider using a smaller font size, more similar to what Finder uses. (We'd probably also want to reduce the default editor font size as well.)
Steps:
Results:
The inserted space is a tab char: the cursor jumps from one end of space to the other with a single press of the arrow key.
(You can also confirm this by cutting & pasting the text into another editor and inspecting it there).
Expected:
Eventually this should be configurable, but for now we should default to spaces, not tabs -- otherwise we can't dogfood with Brackets.
Note that if you select one or more entire lines of text, then press tab, the indentation added that way does use four spaces.
Result:
View of file A is scrolled back to the top. The cursor location (and selection) is still preserved at the bottom of the file, so if you hit the arrow keys the view will jump back down to (approximately) where it was before.
Expected:
Scroll position is preserved.
(The behavior is the window has been resized since last viewing the file is a little tricky, but I think essentially we should aim for keeping the same line at the top of the viewport).
With preferences stored in the browser's local storage, unit tests are now side-affecting the running brackets workspace by persisting the last open project.
When creating multiple new files, File > New should initially propose a unique name like Untitled-1, Untitled-2, etc if Untitled-N already exists.
Keystrokes are ignored. Exception thrown in codemirror:
Uncaught TypeError: Cannot read property 'length' of undefined - codemirror.js:2286
copyStyles - codemirror.js:2286
Line.replace - codemirror.js:2073
updateLinesNoUndo - codemirror.js:550
updateLines - codemirror.js:510
replaceRange1 - codemirror.js:661
replaceSelection - codemirror.js:652
readInput - codemirror.js:716
Result: Arrow disappears (and now you can't tell it's a folder)
Expected: I think having the arrow point down with no children should be enough of an indication.
Steps to reproduce:
Result:
.DS_Store file is listed in root of project folder tree UI
Expected:
Low-level OS files like .DS_Store and Thumbs.db should be hidden from view pretty much always.
Debatably, all dotfiles should be hidden from view... at least by default. (examples: .git folder, .svn folder)
Text descenders (lowercase j, p, y) are visibly clipped in the project title and the editor file name. Use a file or project name with a lowercase j to see the bug.
Currently, we don't do anything to block UI while waiting for an asynchronous step in the middle of an operation, even when that overall operation should probably feel atomic. We probably already have many buggy cases is an async operation were to run slowly.
Here's one example:
In practice, most of the APIs we treat as async today are actually implemented synchronously, so many potential bugs (including the above example) don't happen today. But as soon as we have to a Node- or cloud-based backend, all of these bugs will come to the surface at once.
We should probably have an overarching architecture to deal with marking the start/end of "blocking" operations to eliminate this entire class of bugs.
UI shows that the file is still dirty. Looks like Chris' fix for #52 (in pull request #78) to pass a fake event with target=_FileWriter should fix it.
Uncaught TypeError: Cannot read property 'error' of undefined
Steps:
Result:
Crash in FileCommandHandlers, in the writer.onerror handler nested within handleFileSave().
It looks like it is expecting to be called with a dispatched event as its argument, while NativeFileSystem is invoking it directly and simply passing it an un-wrapped error object (not an event).
Expected:
No crash. User-friendly error dialog appears indicating file not saved.
Result:
Deleted text is restored, but selection is not. You're left with just a blinking cursor where the end of the selection range was.
Expected:
Selection should be restored too. This is what pretty much every other text editor I've ever used does.
Result: Doesn't select the item. On Mac, the expectation would be that clicking anywhere in the row selects the item.
The exceptions are coming form the definition of brackets.fs.readdir in brackets_extensions.js. It looks like JSON.parse doesn't like some of the JSON we are passing it
Result
Cannot dismiss dialog with keyboard. Must use mouse. Note that any keystrokes go a dummy file in the editor!
Expected
There is at least 1 key (or key combination) that dismisses dialog.
Steps to repro:
Results:
Runtime error reported in console
Results:
contents of dragged file is embedded in existing file at the point where it was dropped
Expected
either open file for editing, insert a file reference, or nothing
This might need to get translated into a task for a sprint, but I wanted to start by capturing it here as an issue
Look at the follow unit test in WorkingSetView-test.js (code sample below)
it("should close a file when the user clicks the close button", function() {
// make both docs clean
var docList = DocumentManager.getWorkingSet();
docList[0].markClean();
docList[1].markClean();
// make the first one active
DocumentManager.showInEditor( docList[0]);
// click on close icon of 2nd one
var listItems = this.app.$("#open-files-container").children("ul").children();
var closeIcon = $($(listItems[1]).find(".file-status-icon"));
//expect( closeIcon.toBe(1);
// simulate click
closeIcon.trigger('click');
var listItems = this.app.$("#open-files-container").children("ul").children();
expect( listItems.length ).toBe(1);
expect( listItems.find("a").get(0).text == "file_one.js" ).toBeTruthy();
});
The closeIcon.trigger('click') does not trigger the click event handler. If I use the same code in the console of CES it works. There is probably a inter-window security issue here we need to solve
To make the work that @chrisbank did more beautifuler.
Steps:
Result:
Horizontal scrollbar disappears. It reappears if you scroll back up.
Expected:
Horizontal scrollbar visibility should not change depending on scroll position.
Once you've opened a second file, the bug no longer repros in any file (including the original).
Result: Project panel shows "Loading..." forever. Even if you create a new file, "Loading..." still appears in the tree.
Right now, you can "select" (i.e. text select) most UI elements.
This should probably be turned off by default (inherited) for everything, and turned on for things we want to be able to select (code).
Result:
Two files are created, both with the name you typed in step 8 -- one file in the containing folder, and one file in the (previously empty) subfolder.
Expected:
I assume something is blowing up in the first invocation of File > New, and its Deferred object (or some other event listener) is somehow getting intertangled with the next invocation of New.
Result: doesn't properly extend the selection. This gesture should start by selecting the double-clicked word, and then extending the selection to include other words as you drag.
Steps:
Result:
Native "Open File" dialog appears, but File menu is still open in the background behind it.
Expected:
File menu closes before dialog appears -- this is how all native apps behave.
I assume to fix this we have to open the dialog a little asynchronously to give the browser time to render the DOM update after closing the menu. Seems a little tricky since we'd probably just be guessing how long that will take, making the "fix" just a probabalistic race condition.
This is reproducible in both master and the new implement-file-working-set branch.
If you single-click on another file, typing starts working again.
Results:
First file is still selected in navigator
Expected:
If second file is under current folder, then it should be selected in navigator. If second file is not under current folder, then we should probably show nothing as selected in navigator (I don't think we want to change current folder).
Results:
first file is closed, and mouse is over filename that was second (now first), but (x) icon is not displayed. I have to move mouse to get (x) icon.
Expected:
(x) icon is immediately displayed
NativeFileSystem.requestNativeFileSystem does not currently accept relative paths. Currently, asking for path "." gives the directory "/"
It should return the directory that the window's HTML file is in.
This may be an issue with the brackets-app side of the bridge.
Results
file replaces entire Brackets app!
Expected
file is opened in editor, or nothing
Note: This can't be done until the less-cleanup branch is merged into master.
Steps to repro:
$(".content").css("background-color", "#aaa")
Result: text selection is not drawn.
Our code isn't currently consistent about using == vs. ===. In general, it's probably safer for us to use === everywhere, since == does type conversion. (For example, if you compare an object to a string, the object's toString() method will be called.) We need to establish rules for this, and then fix up the codebase where necessary.
This commit added two files that are illegal filenames on Windows:
46e006f
This was a change by Ty that Glenn merged in this pull request #27.
Attempting to git pull or git merge this commit on Windows causes errors and leaves your source tree in an inconsistent state (a mix of unstaged changes, untracked new files, and files that never even got updated... thus the project is broken because some of the code is updated and some isn't).
Ideally, we would just use a unit-testing shim that feeds fake filenames to the native JSON encoding stuff, rather than having actual bad filenames checked into our source tree. Failing that, maybe we can segregate them into a Mac-only part of the source tree that can be left out on Windows? (That feels like a very Perforce-ey approach, but there must be some way to do that on Git too).
Result: App doesn't lay out correctly. This is probably because we're using (the older version of) flexbox layout, which might not be supported the same way in Firefox.
Result: next line is indented 2 spaces. Should default to 4 as this is more common (and happens to be our default as well).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.