Closed Bug 347200 Opened 18 years ago Closed 18 years ago

Spellchecking defaults do not affect designmode

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
1.8 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta2

People

(Reporter: brettw, Assigned: pkasting)

References

Details

(Keywords: fixed1.8.1)

Attachments

(3 files)

DesignMode document
472 bytes, text/html
Details
patch v1
2.41 KB, patch
brettw
: review+
bryner
: superreview+
Details | Diff | Splinter Review
patch v1 (branch version)
2.50 KB, patch
beltzner
: approval1.8.1+
Details | Diff | Splinter Review 
The same attribute that controls textarea spellchecking should control designmode documents; they should act exactly like textareas. The code to set the defaults for designmode does not seem to work. I can turn it on manually and it works.
Flags: blocking1.8.1?
Attached file DesignMode document — 

    
  
Blocks: 339127

    
    

    
  
Component -> Spell checker


Component: DOM → Spelling checker

    
    

    
  
Actually, this _is_ DOM, not spelling checker.  (Trust me, I wrote the code that's broken here.)  Not that it matters terribly.
Component: Spelling checker → DOM

    
    

    
  
Have a local fix, attaching shortly.
Blocks: 333038

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch v1
        — 
          — Splinter Review
      

    


  
The problem was that the document was creating its editor, THEN setting its "designmode" member variable to true.  During editor creation we eventually wound up asking the document if designmode was on, which at that point it wasn't.

The fix here is simply to set the mEditingIsOn member variable to the desired state before goofing with the editor, and change it back on failure.

        Attachment #232004 -
        Flags: superreview?(bugmail)

        Attachment #232004 -
        Flags: review?(brettw)

    
    

    
  


  
Here's the branch version of the same patch, which is identical except for the file offset.

    
    

    
  
Setting target milestone so this will show up on blocking radar.
Target Milestone: --- → mozilla1.8beta2
Flags: blocking1.8.1? → blocking1.8.1+

    
    

    
  
Comment on attachment 232004 [details] [diff] [review]
patch v1

looks good

        Attachment #232004 -
        Flags: review?(brettw) → review+

        Attachment #232004 -
        Flags: superreview?(bugmail) → superreview+

    
    

    
  
Checked into trunk to bake.

/mozilla/content/html/document/src/nsHTMLDocument.cpp 3.693
Whiteboard: [baking]

    
    

    
  
Comment on attachment 232005 [details] [diff] [review]
patch v1 (branch version)

Requesting branch approval once this has baked.  Probably only needs one night, and I'd like to get this in pre-freeze since this is a regression from B1.

        Attachment #232005 -
        Flags: approval1.8.1?

    
    

    
  
Comment on attachment 232005 [details] [diff] [review]
patch v1 (branch version)

a=drivers, please go ahead and land on the branch.

        Attachment #232005 -
        Flags: approval1.8.1? → approval1.8.1+

    
    

    
  
Fixed on branch.

/mozilla/content/html/document/src/nsHTMLDocument.cpp 3.615.2.29
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [baking]
Depends on: 348497

    
    

    
  
This caused crash bug 348497.
Depends on: 348981
Component: DOM → DOM: Core & HTML

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: