Sorry I was just testing out the extension and sadly it doesn't seem to be working.

Restarted Chrome
Disabled other Gmail-related extensions
Tried in Incognito window

Chrome Version 47.0.2526.106 (64-bit)
OSX 10.11.2

Anybody else having trouble or is this me?

Screenshot:

Please provide this as a safari extension. Apple provides a guide on how to build safari extensions based on Chrome extensions.

It would be nice to be able to get more information/reasoning behind the quote suggesting why a word/phrase should not be used. Since each quote has a source url behind the scenes, maybe the block displaying the quote to the user can hyperlink to that source url.

One of the challenges of the manual release process is that the version number needs to be incremented manually and release notes need to be generated for the change set. To automate this, use the semantic-release package.

To enable a round of testing before releasing changes to the broader public, we should also set up a pre-release branch.

Finally, set up a linter and use husky to ensure that commit messages use the correct format.

This is an awesome idea, thanks for your work on it so far!

Any plans to enable this on things other than GMail?

Like, say, GitHub Issues? 😄

Hi - when the plugin is enabled, my line breaks aren't being respected especially when trying to hit backspace a few times to join two lines together.

Not sure how best to illustrate this outside a screencast which I can do if need be.

I need to type emails in German and English equally often on an English keyboard layout. Typing umlauts via ALT+u and e.g. u for ü is broken when enabling the extension.

Steps

1. Open new email with enabled just not sorry extension
2. Type alt+u to get ¨ and any of the following characters a, u, o

Expected
¨ will be replaced with ü when typing u

Actual
¨ will not be replaced and the characters appear as: ¨u

Tami tested the v2.0.0-beta.7 release and found issues with the highlighting on both Outlook and GMail.

From Tami:

Outlook isn't working right… not everything gets caught but I'm not sure why because some were copy and pasted and fine and others were not and the same goes for typed fresh and new.

For gmail I had a similar experience

I thought the we/i believe/feel worked, but it seems the We's are missing. Also weirdly when I added a space after the try that doesn't trigger, both it and does that make sense triggered. Here's the copy:

sorry i think that just sucks
we believe that trying to actually 
try
does that make sense ?
i believe 
we feel 
i feel 
try 

Can you publish a Mac OS X Mail Plugin?

Seems like with the newest update, the spellchecker triggers on keypress, so words get underlined as incorrect when you're in the middle of typing them.

Interestingly this only happens on my work gmail, not my personal. Will keep digging to see if I can get better reproduction information than that.

The color that underlines words currently looks just like the underline that Chrome uses to indicate misspelled words. So when I've written words that get flagged, it's not clear to me if they are simply misspelled, or if JustNotSorry is trying to highlight them.

I'd propose/request the use of a different color -- perhaps purple or blue?

Chrome: Verzió: 81.0.4044.92 (Hivatalos verzió) (64 bites), No other extensions, Default theme, Tested with 2 profiles
Just Not Sorry -- the Gmail Plug-in: Verzió 1.6.1
Windows 10 Pro: Verziószám 10.0.18362 build 18362

I can open the compose dialog, fill out everything, press send, and then nothing happens. Nothing in the console either.

Currently, the process of releasing a new version of the extension to the Chrome Web Store is completely manual and requires a number of different steps. Because of this, there are many opportunities for human error. Finding the credentials to actually do the release has also been a challenge in the past.

The goal of this ticket is to fully automate the release process so that when code is merged to the master branch and the CI build passes, the changes should get automatically deployed to the web store using the Webstore API.

To enable a round of testing before releasing changes to the broader public, configure a workflow that will publish changes in the pre-release branch to the trusted testers channel. Establish an automated release to beta.

Depends on #71

On outlook.live.com, the first new email that you compose by clicking the "New message" button will display warnings as expected. But if the "New message" button is clicked a second time, the warnings will no longer appear in the new compose text area. If you then switch back to the prior email, warning checking will be broken there, too.

The issue is related to the way JustNotSorry is watching for additions and removals of contentEditable divs in the DOM.

In JustNotSorry.js, the code is looking for changes in the number of contentEditable divs to determine if it needs to start watching a newly added div:

  handleContentEditableDivChange(mutations) {
    let divCount = this.getEditableDivs().length;
    if (divCount !== this.state.editableDivCount) {
      this.setState({ editableDivCount: divCount });
      if (mutations[0]) {
        mutations
          .filter(
            (mutation) =>
              mutation.type === 'childList' &&
              mutation.target.hasAttribute('contentEditable')
          )
          .forEach((mutation) => this.applyEventListeners(mutation.target));
      }
    }
  }

It's a performance optimization to keep the code from recalculating the state every time nodes are added or removed from the DOM.

This works fine in GMail because each new email gets its own compose text area.

In outlook.live.com, though, the compose text area gets replaced by a new contentEditable DOM node. The remove and the add occur together, so the divCount doesn't change and the logic to start watching the new contentEditable div never gets triggered.

One idea for fixing this would be to remove the editableDivCount check and instead look at the array of mutations to find newly added contentEditable divs.

This would be interesting to be able to switch modes like "polite" where there would be suggestion on selecting particular words that are more polite than others.

• Deliver the report this afternoon or you are fired.

turned into

• Delivering the report this afternoon will allows us to present things on time to the board so they can make an effective decision.

This would be something difficult to pull off but so worthy.

In the 2.X beta version of the extension (not yet released to the public), if you create a really long email with a lot of warning words, the performance of both GMail and Outlook slow to a crawl.

To reproduce, try pasting this paragraph in to a compose window over and over again until the mail app hangs:

I'm just so sorry about being sorry.  It's just so crazy about being sorry. I'm sorry about being so sorry. Does that make sense? I'm actually sorry about being so sorry.  Yes, I'm sorry about that. In my opinion, I am sorry about this being slow.

The 1.6.3 version of JNS that's out to the public can handle these long emails with no issues.

This issue is blocking the release of the 2.X version of JNS.

There is a lot of weak word wordlist out there that may be of use.

• https://rubineducation.com/writing-skills-words-weak/
• https://fortune.com/2016/10/04/professional-email-tips-mistakes/
• https://bloggingbistro.com/11-weak-words-that-dilute-your-blog-posts-impact/
• https://www.theladders.com/career-advice/8-words-that-make-you-look-weak-in-an-email
• https://www.revsquared.ca/2018/12/06/weak-phrases-to-avoid/
• https://expresswriters.com/50-weak-words-and-phrases-to-cut-out-of-your-blogging/
• https://medium.com/swlh/these-weak-words-and-phrases-are-killing-your-writing-c997876cf5d2
• https://goinswriter.com/weak-words/
• https://www.monster.co.uk/career-advice/article/seven-words-that-make-you-sound-less-confident-in-emails
• https://time.com/2889520/lack-of-confidence-words/

Add support for the superhuman web mail client: https://mail.superhuman.com/

I think it would be great if just not sorry support could be extended to inbox.google.com , and possibily others as well.

This is a simple issue, but could you add a link to the extension to the GitHub metadata and the top of the README, for people who just want to install the extension.

If a warning is broken onto two lines, it remains highlighted:

It should be highlighted as a spelling error perhaps in this case, but not as a warning.

I originally balked when raising this because I thought it may be beneficial for keywords that are phrases, but it only triggers when a word is broken up, not when broken on a space, so there is no benefit that I can see:

This is on Chrome Version 74.0.3729.169 (Official Build) (64-bit MacOS). Note the two highlights are for the warnings "should" and "I think" far above.

The JustNotSorry code base is showing its age. It uses old JavaScript syntax and conventions. It isn't able to make use of npm packages for the extension either. This ticket starts the modernization process by converting to ES6 syntax, npm, and webpack.

• Convert the src files to ES6 syntax -- classes, imports, exports, etc.
  • background.js and the code in the options directory can stay as-is since those are loaded separately
  • ScriptLoader.js and lib/head.load.min.js should not be needed anymore. These files were a performance enhancement and helped control the loading order of the source files and libraries. After converting to webpack, all that code will be bundled into a single javascript file.
• Use npm packages instead of the libraries in the lib folder
• Set up webpack to bundle the code into a single file
  • It's possible that you might need to use the webpack babel-loader to get the ES6 syntax to work, but chrome has good support for it these days and so hopefully you won't need it.
  • Make sure to change manifest.json to use the new bundle file

Acceptance criteria

• The extension should function exactly the same as it does currently
• All the tests should pass

Noticed this behavior which I assume is unintentional.

Repro steps:

1. Write some text in a new email in gmail. Hit return once or twice, type "thanks " on its own line
2. Hold CMD and press Delete (probably works on PC with ctrl-backspace)

Expected result: Delete the entire current line and leave cursor at the beginning of the current line (ie. cmd-delete does not change the line that the cursor is on.

Actual result: When the plugin is enabled, cmd-delete deletes the entire line and then moves the cursor up to the end of the previous text, blowing away any whitespace in between.

Disabling the plugin and refreshing the page fixes the issue.

Rewrite the UI portion of JustNotSorry in React, or more specifically Preact because of its smaller size.

Rationale:

• Using a virtual DOM would help improve performance since it would enable us to only update DOM elements that have changed (as opposed to the current method which involves adding and removing the highlight elements frequently)
• It will allow us to take advantage of newer technology and libraries, enabling us to add features with less effort
• Def Method engineers have experience with React so using it would help with maintenance

Currently, just-not-sorry uses a jasmine SpecRunner file to run its tests. This doesn't support running from the command line and so there's no way to set up a continuous integration build. The goal for this ticket is to:

1. Upgrade the test runner to the latest jasmine (3.x)
2. Set up npm or yarn and enable the tests to be run from the command line using npm test
3. Set up a continuous integration build using Circle CI or CodeShip
4. Tie the CI build into the GitHub pull request workflow so that all tests need to pass before a PR can be merged

I just feel like the flat-out ban of the word "just" is just ruling out justifiably non-undermining text...

For example, it highlights this sentence as bad:

It was great speaking with you just now! 

or this:

Attached is the file we just talked about.

Just isn't always a kind of apologetic and demeaning word (although I agree, when it is inserted right after "I" then often it is...)

But it can also be kind of an adjective that refers to a short amount of time...

For example, would the phrase Just-In-Time Compilation have the same meaning if we remove the "just"? 🤔

repro steps:

1. write a few words "the quick brown fox"
2. using the keyboard, highlight the previous 3 words (on a mac, option-shift-leftarrow 3 times)
3. using the keyboard, bold the selection. (on a mac, command-B)

Expected result: 3 highlighted words remain highlighted (now bold)
Actual result while plugin enabled: 3 highlighted words are bolded, cursor is moved to the end.

This is kind of a workflow killer for keyboard users :-/

Use case: I don't feel like I apologize too much, and I'd like to never get warnings on words like "sorry", "apologies", and "apologize". I should be able to see a list of all warning phrases on the options pane and uncheck the ones I don't want.

This would have the side effect of making the full list of warning phrases visible in a second location beyond the documentation, per #57.

Jasmine and jasmine-jquery are showing their age -- it's difficult to mock ES6 module imports with jasmine and jasmine-jquery hasn't been updated in years. Switch to use Jest as the test framework.

I recently composed a email of introduction on the topic of mentoring in which I found the suggestions from Just Not Sorry very distracting. I have emailed Caren a screenshot - it's too sensitive to post here.

As a result, I would like to be able to temporarily turn off Just Not Sorry when composing a particularly difficult/sensitive email, and have it automatically start again the next time I start composing a new email.

Google Inbox is no longer offered as a service. inbox.google.com redirects to mail.google.com. Code for inbox.google.com is no longer used and should be removed.

https://www.blog.google/products/gmail/inbox-signing-find-your-favorite-features-new-gmail/

Just installed and testing on my gmail:

seems to be missing some decoding perhaps?

Setup: Open a reply in gmail, type some stuff, press enter to go to a new line and type some more stuff

Action: Press backspace to delete all the characters in the new line

Expected: Cursor stays on that new line

Actual: Cursor jumps to the end of the previous line

Confirmed that is the Just Not Sorry app causing this by disabling it and noticing the behavior stopped, then re-enabling and seeing the behavior happen again.

Using Chrome 47.0.2526.106 (64-bit) on Mac OSX 10.9.5

As observed by textlint/textlint#750 it would be useful if TextLint has this feature.

Assisting documentation: https://textlint.github.io/docs/rule.html

Reasoning to have this: The software could be applied to MarkText or Zettlr, or some other text editor.

Create a user option to set the color of the warning indicator.

(ref #1)

I may be sounding the alarm too soon, but I thought I'd mention a problem I found before somebody else does. If it turns out to be my own fault and this is proven to be a non-issue, then so be it.

I sent myself a message in Google Mail (my organization uses an enterprise version set up for us by Google) which contained only the word "sorry" followed by my email signature. When I opened the message I'd received, then chose the Show original feature, the "text/html" part of the message contained the following:

<div dir=3D"ltr"><div><span title=3D"Using "sorry" frequently und=
ermines your gravitas and makes you appear unfit for leadership. --Sylvia A=
nn Hewlett"><span title=3D"Using "sorry" frequently undermines yo=
ur gravitas and makes you appear unfit for leadership. --Sylvia Ann Hewlett=
">sorry</span></span></div><div><br><div><div><div><div dir=3D"ltr"><=
div><div dir=3D"ltr"><div dir=3D"ltr"></div></div></div></div></div></div>
</div></div></div>

(I've edited this slightly to remove my email signature and its immediately enclosing markup.)

Notice there are two HTML span elements which contain JNS warning messages about using the word "sorry". This could be embarrassing if some recipient noticed this in a message.

I had installed JNS by downloading a ZIP file of this repo, extracting it on my computer (running OS X v10.11.1), and using the Load unpacked extension... button on extensions page in Chrome ("Version 47.0.2526.106 (64-bit)"). I ran it and it seemed fine.

I went on to make some minor changes to just-not-sorry.css. To see them, I used the Reload (⌘R) link on the extensions page to reload my changes. They didn't appear at first, so I also reloaded my Google Mail page. In my "Drafts" folder, I reopened the message and made some edits to the message to see the new style I'd specified. It looked fine, so I sent the message.

I didn't suspect that the JNS message would appear in my email at all. I just happened to inspect the elements of the message and I noticed it there.

I suspect that the markup may have gotten included in the message because I reloaded the page while JNS had the text highlighted. It might also have something to do with the enterprise version of Google Mail I'm using. I'd like to know whether anybody else can reproduce this problem, either with the GitHub project or using the extension installed from Chrome's web store.

Let me know if more details are needed.

Use case: I am composing an email and I genuinely wish to apologize. I want to dismiss the underline on the word "sorry" and not see it again in this email, because I don't plan to change what I wrote.

Many of the outstanding bugs (#10, #12, #25, and #27) and the fixed bugs (#6, #8, #22) are related to how highlighting and cursor positioning are done. I've tried different fixes for the outstanding bugs but nothing has worked reliably and the code gets ugly quickly. When that happens consistently, it's a design smell and the design needs to be reconsidered.

The core issue is that when just-not-sorry highlights a word, it mutates the DOM. When words are edited (e.g., when "just for" gets changed to "justification for"), it needs to strip out the highlighting by deleting the DOM node. Deleting the node causes the cursor position to be lost. To address this, we programmatically set the cursor position back to what it was before, but this fails for certain edge cases (#10, #25) or has other side effects (#27). Finally, before the email is sent, it needs to strip out the highlighting, but for certain edge cases the stripping fails (#12).

The new design should do the highlighting without mutating the part of the DOM that contains the text you're editing.

An additional benefit of the redesign will be that we can more easily extend just-not-sorry to other web email clients (inbox, hotmail, etc. -- #4, #20) because we won't need to write and test new logic to strip out the highlighting for each email client.

The spike in commit c36981f shows that creating an overlay with the highlighting using Range.getBoundingClientRect is a viable solution.

This ticket is to track the work required to turn the spike into a production-ready implementation.

Please read this: http://nymag.com/thecut/2015/07/can-we-just-like-get-over-the-way-women-talk.html

http://thewritepractice.com/better-writer-now/ explains why the following words / phrase could negatively impact someone's message.

“One of”
"Some"
“Thing”
“Very”
"So, mostly, most times, in order to, often, oftentimes"

The article lists others, but warning underlines for the above would help users of the just-not-sorry extension write with greater clarity and specificity.

Thanks for this helpful extension and your consideration of this suggestion.

While testing the last few pull requests, I've noticed that typing into long emails is very laggy. I profiled the code and found that the checkForWarnings function in just-not-sorry is the culprit. It adds and removes the warnings each time you type a character. This causes Chrome to recalculate the layout of the DOM over and over again, which is slow when there are a lot of nodes being impacted. We should implement a less expensive method of handling warnings to address this issue. The changes needed to fix this issue could also serve as a base for being able to implement #59 .

As we work on adding support for additional browsers, such as Firefox #68, it will become increasingly important to run tests on all of those browsers to ensure that the plug-in works as expected and does not inadvertently break any Gmail functionality.

The goal of this ticket is to add an automated web tests that:

1. logs in to a test Gmail account
2. opens a compose window
3. types text that should result in a warning being shown
4. ensures that the underline is showing up and the correct popup is shown
5. confirms that it is still possible to send this email by sending it to the test Gmail account

With the addition of the web-ext tool in #89, it is now possible to start an instance of Chrome with the plug-in installed.

GitHub Actions can be used to run E2E web tests on various platforms. For example: https://github.com/cypress-io/github-action

Hi, I'm trying to add Hebrew warnings in the src/Warnings.js file and It doesn't work.
I guess it has something to do with the ASCII characters.
What am I supposed to do?

Request from Tami to add support for outlook.com.

I installed the extension and it doesnt seem to work:

My user agent:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36

The links to articles are a great addition to this README that I don't think were there last time I looked at this repo!

I think it would be awesome if the README spelled out which phrases it highlights. For example, I wanted to suggest adding "I'll try" to the list but wasn't sure if that was already in the list. Also, for general users it would be nice to see what all the supported phrases are so they can easily and quickly give feedback or suggest new things! ❤️

Firefox has almost the same APIs as Chrome https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs

Most extensions take minutes to port https://vimeo.com/241435808

When just-not-sorry is disabled in Chrome (by going to chrome://extensions/ and unchecking the "Enabled" checkbox), the JNS icon is immediately removed from the address bar. However, Google Mail windows that were open when JNS was running will continue to run. If the page is reloaded, JNS will no longer run. Doing that will not be immediately obvious the the majority of users.

Add a check to the code to not run if the extension is not enabled.