Closed Bug 1217877 Opened 10 years ago Closed 10 years ago

FireFox Nightly 44.0a1 (2015-10-22) crash when bolding an item in Confluence

Categories

(Core :: DOM: Editor, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: claudijd, Unassigned)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

I'm not sure if this is a security issue or not yet. I really don't have enough experience with FireFox bug hunting to know just yet, but I was updating the Confluence wiki while using the FireFox nightly 44.0a1 (2015-10-22) build and when using the bold function in the editor, it managed to crash all tabs. I have been able to reliable reproduce this bug and I have also captured a screenshare video on how to reproduce. Here's the text version if you're not into videos: Edit page => Select text => make it bold (either via the bold button or command B) and it should crash all the tabs. I had this happen on the previous nightly and then I upgraded to the latest and had the same issue.
Did you submit the crash reports? If not, can you please do so? If you have done so, can you please go into about:crashes, click the links corresponding to the crashes (the time + date should enable you to tell them apart, unless you crash very often...) and copy-paste the URLs into a new comment? The screencast may also be helpful - did you mean to link to it?
Flags: needinfo?(jclaudius)
Gijs: Yes, I attached on creation, but on second review it may have been ever so slightly over the upload limit. I will re-record/trim it or change the codec and re-attach shortly. I also submit the crash reports, but I will also go and try to grab the content you suggested as well.
Flags: needinfo?(jclaudius)
Also, BTW, I just upgraded to 44.0a1 (2015-10-23) and I can no longer reliably reproduce. I also was unable to reproduce this bug on the latest prod release of FireFox. I still intend to provide the screen view just in case it reveals anything useful for dev purposes.
OK, so this is a nullptr crash -> doesn't need to be sec-sensitive. It's nice that it got fixed in current nightly... it might be worth chasing up when/how that happened, though... Masayuki-san, I see IME on the stack - do you have any ideas looking at the crashreports / screencast?
Group: firefox-core-security
Component: General → Editor
Flags: needinfo?(masayuki)
Keywords: crash
Product: Firefox → Core
Great, thanks!
CORRECTION: it's still present in the nightly release for 44.0a1 (2015-10-23). Here's another crash report... https://crash-stats.mozilla.com/report/index/229d9329-4eb3-4756-8f23-c80962151023
I have no idea. According to the crashed line, a node stored in nsContentIterator has removed from the DOM tree since looks like that its GetParent() returns nullptr. > // post-order > nsINode* parent = node->GetParentNode(); > nsIContent* sibling = nullptr; > int32_t indx = 0; > // get the cached index > NS_ASSERTION(!aIndexes || !aIndexes->IsEmpty(), > "ContentIterator stack underflow"); > if (aIndexes && !aIndexes->IsEmpty()) { > // use the last entry on the Indexes array for the current index > indx = (*aIndexes)[aIndexes->Length()-1]; > } else { > indx = mCachedIndex; > } > // reverify that the index of the current node hasn't changed. not super > // cheap, but a lot cheaper than IndexOf(), and still O(1). ignore result > // this time - the index may now be out of range. > if (indx >= 0) { > sibling = parent->GetChildAt(indx); <- crashed this line! claudijd: Is this a recent regression? Can you look for a regressed build with mozregression? http://mozilla.github.io/mozregression/install.html Unfortunately the tool doesn't have GUI on Mac OS X, though.
Flags: needinfo?(masayuki) → needinfo?(jclaudius)
masayuki: installing the tool now, I'll let you know what I come up with. Thanks for the reference.
Flags: needinfo?(jclaudius)
masayuki: I spent some time trying to use mozregression and I'm running into an issue with being able to list the nightly releases. When I run 'mozregression --list-releases' the latest valid release is 2015-06-29. I also started to play with the config file a bit and have yet to figure out how to tell it to look for the nightly builds instead of what looks to be beta releases. Here's my config file in case you have any guidance: # ------ mozregression configuration file ------ # Most of the command line options can be used in here. # Just remove the -- from the long option names, e.g. # bits = 32 # persist-size-limit = 15.0 repo="mozilla-aurora" persist = /Users/jclaudius/.mozilla/mozregression/persist persist-size-limit = 20.0 Please note that I get the same behavior with or without the repo specification.
(In reply to Jonathan Claudius [:claudijd] from comment #12) > masayuki: I spent some time trying to use mozregression and I'm running into > an issue with being able to list the nightly releases. When I run > 'mozregression --list-releases' the latest valid release is 2015-06-29. Thank you for your test! But I'm surprised at the date. Isn't this a new regression?? Unfortunately, we touched neither nsContentIterator.cpp nor ContentEventHandler.cpp around the day... http://hg.mozilla.org/mozilla-central/filelog/26078ba1c7be/dom/base/nsContentIterator.cpp http://hg.mozilla.org/mozilla-central/filelog/05d85d9bbce4/dom/events/ContentEventHandler.cpp
Hmm, I cannot reproduce this with simple test case: http://jsfiddle.net/d_toybox/2uyggfv8/1/ We need to know how the editor make selected text bold.
(In reply to Jonathan Claudius [:claudijd] from comment #12) > masayuki: I spent some time trying to use mozregression and I'm running into > an issue with being able to list the nightly releases. When I run > 'mozregression --list-releases' the latest valid release is 2015-06-29. Yeah, these are public releases. By default mozregression will always use nightly builds, though. Just e.g.: mozregression --good 2015-10-01 will try to find a regression between today and the first of October on the nightly channel.
Same problem here. Now 44 is the version of Fx Dev. Edition (44.0a2 20151103004217) and the problem exist also in Wordpress, with or without using keyboard commands (you can set a bold text with ctrl+b or select the bold button in Wordpress WYSIWYG toolbar). https://crash-stats.mozilla.com/report/index/bp-9c5fdf13-38fd-4581-86c5-cd7062151105 https://crash-stats.mozilla.com/report/index/bp-dfc297da-63b2-4db5-a0b6-b46e02151105 https://crash-stats.mozilla.com/report/index/bp-4c0cb8bf-9a52-4dd2-b319-e0a572151105 https://crash-stats.mozilla.com/report/index/bp-c228ade0-e16d-48c8-a6cf-491df2151105
I'm on dev edition and have been seeing this in Confluence. I've submitted the crashes as well, but I think from my other machine. This email address should be attached to them. I believe it will bold ok if you do the mark-up by hand, but definitely crashes via the kb shortcut and the button. Haven't tried WP yet, but can if it'll be helpful.
(In reply to Majken Connor [:Kensie] from comment #18) > I'm on dev edition and have been seeing this in Confluence. I've submitted > the crashes as well, but I think from my other machine. This email address > should be attached to them. > > I believe it will bold ok if you do the mark-up by hand, but definitely > crashes via the kb shortcut and the button. Haven't tried WP yet, but can if > it'll be helpful. I don't have access to Confluence; can you try to run mozregression to figure out when this regressed? (see also comment #16)
Flags: needinfo?(majken)
I can, also happy to hook people up on the community ops instance, https://confluence.mozilla-community.org/
Flags: needinfo?(majken)
Hmm, bug 1224101 was already fixed but you still reproduce this bug only in Confluence, we might need risky fix on Aurora. Please, please hurry up to check the regression range because we don't have much time to fix this bug due to Mozlando.
Crash Signature: [@ nsContentIterator::NextNode]
And also I'd like to know if this is reproduced on the latest Nightly build since we've already fixed the bug without backing out (bug 1218032).
Sorry, I've been busy. I can give people access to confluence, or if you have access to mana you can test yourself.
Just updated Aurora and it seems to be fixed - 44.0a2 (2015-11-28)
Does the latest Aurora nightly work for you as well, Jonathan?
Flags: needinfo?(jclaudius)
I just tested on 45.0a1 (2015-12-01) and I was unable to replicate the issue.
Flags: needinfo?(jclaudius)
What about Aurora? :) Just looking for confirmation on comment 24 before closing this out as worksforme.
Flags: needinfo?(jclaudius)
@Ryan I just tested on Aurora 44.0a2 (2015-12-01) and I was unable to replicate the issue.
Flags: needinfo?(jclaudius)
Fantastic, thanks for testing! Let's call this fixed by bug 1224101.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: